Re: [PATCH V3] check-ignore: Add option to ignore index contents
On 15:27, Thu 05 Sep 13, Junio C Hamano wrote: Now the long option name is --no-index, it makes me wonder if -i is a good synonym for it, and the longer I stare at it, the more certain I become convinced that it is a bad choice. I had originally called it --ignore-index at which point -i made more sense! Dave -- 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 10/38] pack v4: commit object encoding
Nicolas Pitre n...@fluxnic.net writes:
This goes as follows:
- Tree reference: either variable length encoding of the index
into the SHA1 table or the literal SHA1 prefixed by 0 (see
encode_sha1ref()).
- Parent count: variable length encoding of the number of parents.
This is normally going to occupy a single byte but doesn't have to.
- List of parent references: a list of encode_sha1ref() encoded
references, or nothing if the parent count was zero.
- Author reference: variable length encoding of an index into the author
identifier dictionary table which also covers the time zone. To make
the overall encoding efficient, the author table is sorted by usage
frequency so the most used names are first and require the shortest
index encoding.
- Author time stamp: variable length encoded. Year 2038 ready!
- Committer reference: same as author reference.
- Committer time stamp: same as author time stamp.
The remainder of the canonical commit object content is then zlib
compressed and appended to the above.
Rationale: The most important commit object data is densely encoded while
requiring no zlib inflate processing on access, and all SHA1 references
are most likely to be direct indices into the pack index file requiring
no SHA1 search into the pack index file.
May I suggest a small change to the above, though.
Reorder the entries so that Parent count, list of parents and
committer time stamp come first in this order, and then the rest.
That way, commit.c::parse_commit() could populate its field lazily
with parsing only the very minimum set of fields, and then the
revision walker, revision.c::add_parents_to_list(), can find where
in the priority queue to add the parents to the list of commits to
be processed while still keeping the object partially parsed. If a
commit is UNINTERESTING, no further parsing needs to be done.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
---
packv4-create.c | 119
1 file changed, 119 insertions(+)
diff --git a/packv4-create.c b/packv4-create.c
index 12527c0..d4a79f4 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -14,6 +14,9 @@
#include pack.h
#include varint.h
+
+static int pack_compression_level = Z_DEFAULT_COMPRESSION;
+
struct data_entry {
unsigned offset;
unsigned size;
@@ -274,6 +277,122 @@ static int encode_sha1ref(const unsigned char *sha1,
unsigned char *buf)
return 1 + 20;
}
+/*
+ * This converts a canonical commit object buffer into its
+ * tightly packed representation using the already populated
+ * and sorted commit_name_table dictionary. The parsing is
+ * strict so to ensure the canonical version may always be
+ * regenerated and produce the same hash.
+ */
+void *pv4_encode_commit(void *buffer, unsigned long *sizep)
+{
+ unsigned long size = *sizep;
+ char *in, *tail, *end;
+ unsigned char *out;
+ unsigned char sha1[20];
+ int nb_parents, index, tz_val;
+ unsigned long time;
+ z_stream stream;
+ int status;
+
+ /*
+ * It is guaranteed that the output is always going to be smaller
+ * than the input. We could even do this conversion in place.
+ */
+ in = buffer;
+ tail = in + size;
+ buffer = xmalloc(size);
+ out = buffer;
+
+ /* parse the tree line */
+ if (in + 46 = tail || memcmp(in, tree , 5) || in[45] != '\n')
+ goto bad_data;
+ if (get_sha1_lowhex(in + 5, sha1) 0)
+ goto bad_data;
+ in += 46;
+ out += encode_sha1ref(sha1, out);
+
+ /* count how many parent lines */
+ nb_parents = 0;
+ while (in + 48 tail !memcmp(in, parent , 7) in[47] == '\n') {
+ nb_parents++;
+ in += 48;
+ }
+ out += encode_varint(nb_parents, out);
+
+ /* rewind and parse the parent lines */
+ in -= 48 * nb_parents;
+ while (nb_parents--) {
+ if (get_sha1_lowhex(in + 7, sha1))
+ goto bad_data;
+ out += encode_sha1ref(sha1, out);
+ in += 48;
+ }
+
+ /* parse the author line */
+ /* it must be at least author x x 0 +\n i.e. 21 chars */
+ if (in + 21 = tail || memcmp(in, author , 7))
+ goto bad_data;
+ in += 7;
+ end = get_nameend_and_tz(in, tz_val);
+ if (!end)
+ goto bad_data;
+ index = dict_add_entry(commit_name_table, tz_val, in, end - in);
+ if (index 0)
+ goto bad_dict;
+ out += encode_varint(index, out);
+ time = strtoul(end, end, 10);
+ if (!end || end[0] != ' ' || end[6] != '\n')
+ goto bad_data;
+ out += encode_varint(time, out);
+ in = end + 7;
+
+ /* parse the committer line */
+ /* it must be at least committer x x 0 +\n i.e. 24 chars */
+ if (in + 24 = tail || memcmp(in, committer , 7))
+
Re: Problem setting up a shared git repository
Am 9/5/2013 23:43, schrieb Eyal Zinder: I'm trying to setup a distributed development repository with a central repository acting as the production copy. I'm doing so on a Windows file share with no SSH / HTTP accessibility. Basically each developer will have their own copy of the project, and the shared drive should have a copy of the master copy (prod/master branch), along with the work-tree files. The idea is that any developer should be able to do independent development, staged commits, etc.. then push to the central (origin) repository, and production scripts will reflect these changes upon a push. I got pretty close to this setup by creating a bare repository on the file share server (f:\GitDBs\foo.git), then cloning the bare repository onto the production path like so: git clone f:\GitDBs\foo.git foo The setup sounds reasonable. I cloned the bare repository just the same onto my local dev path.. and proceeded with development. This worked fine, and I was able to push / pull changes into origin (bare repo), and then I would go to my prod (f:\foo) repository (clone of bare f:\GitDBs\foo.git), then pull the changes.. So far my understanding is that your production directory only ever issues pulls from the bare repository. That is OK. The problem I faced later on was in parallel development, when changes were made to a file in one repository, and at the same time other changes made to the same file in another repository.. I couldh't push changes from the dev\foo to prod\foo or to origin.. Define couldn't push. What are the error messages? Is it important that it is *the same file* to which changes were made at the same time? Do you have receive.denyNonFastForwards set in the bare repository? I'm completely lost at the moment.. I try to set --git-dir or --work-tree and I get mixed results.. Don't do that, it should not be necessary in your setup. -- Hannes -- 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-gui: Modify push dialog to support Gerrit review
Junio C Hamano gits...@pobox.com writes:
Isn't the right way to improve the situation to let the command line tools
know how the user wants to push things out and just have Git-GUI delegate
the choice to the underlying git push?
Thank you for all the constructive feedback. I realize that it is not the way
forward to remove the selection of branches to push.
What I consider now, is to pursue the idea that Junio presents above: just let
the gui tool use whatever is configured for the selected remote. I have,
however not been able to come up with a solution that looks nice. What I have
been trying now is the following little modification:
diff --git a/git-gui/lib/transport.tcl b/git-gui/lib/transport.tcl
index e5d211e..1709464 100644
--- a/git-gui/lib/transport.tcl
+++ b/git-gui/lib/transport.tcl
@@ -95,7 +95,9 @@ proc start_push_anywhere_action {w} {
set cnt 0
foreach i [$w.source.l curselection] {
set b [$w.source.l get $i]
- lappend cmd refs/heads/$b:refs/heads/$b
+ if {$b nw {default}}{
+ lappend cmd refs/heads/$b:refs/heads/$b
+ }
incr cnt
}
if {$cnt == 0} {
@@ -149,6 +151,7 @@ proc do_push_anywhere {} {
-height 10 \
-width 70 \
-selectmode extended
+ $w.source.l insert end default
foreach h [load_all_heads] {
$w.source.l insert end $h
if {$h eq $current_branch} {
The idea is to insert a default entry in the branch selection list, and
then skip that when building the command. Then you can avoid having refs on the
command line and just let git act according to configuration.
How about that? Any smarter way to do it?
BR Jørgen
Re: [PATCH v3] Document pack v4 format
On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote: Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com --- Should be up to date with Nico's latest implementation and also cover additions to the format that everybody seems to agree on: - new types for canonical trees and commits - sha-1 table covering missing objects in thin packs Great! I've merged this into my branch with the following amendment: I'd like to propose another change in the format to basically limit the use of sha1ref format \0SHA-1 to tree entries only. All forms of deltas must have non-zero sha1 index (i.e. reference to SHA-1 table). It will simplify handling code, and I think it makes sense too diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt index d0c2cde..399416b 100644 --- a/Documentation/technical/pack-format.txt +++ b/Documentation/technical/pack-format.txt @@ -74,7 +74,8 @@ Git pack format Blobs and tags are deltified and compressed the same way in v3. Commits are not deltified. Trees are deltified using - special copy sequences. + special copy sequences. The base object name index in deltified + format must not be zero (i.e. it must point to SHA-1 table). Trees and commits in canonical types are in the same format as v2: in canonical format and deflated. They can be used for @@ -166,6 +167,8 @@ Git pack format set, it will be followed by a base tree SHA-1. If it's not set, the last base tree will be used. +base_sha1_index cannot be zero and followed by full SHA-1. + == Original (version 1) pack-*.idx files have the following format: - The header consists of 256 4-byte network byte 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: Problem setting up a shared git repository
On Thu, 5 Sep 2013 14:43:52 -0700 (PDT) Eyal Zinder ezin...@yahoo.com wrote: [...] The problem I faced later on was in parallel development, when changes were made to a file in one repository, and at the same time other changes made to the same file in another repository.. I couldh't push changes from the dev\foo to prod\foo or to origin.. [...] Did Git tell you the push failed because of non-fast-forward update? -- 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 0/5] branch: Fix --track on a remote-tracking non-branch
Hi, Per Cederqvist alerted me to a change in v1.8.3.2 that broke his build/test infrastructure. Specifically, before 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) Git allowed a local branch to --track anything within refs/remotes/*, and in 41c21f2, I changed the rules to require a configured remote with a matching fetch refspec when setting up the upstream configuration variables (so that there was no ambiguity on how to set branch.name.remote and branch.name.merge). So far so good. However, in addition to requiring a matching remote/refspec, I also (for reasons that are still unclear to me) added a requirement that the resulting remote ref name (to be stored into branch.name.merge) must start with refs/heads/ (see the last line of branch.c:check_tracking_branch()). Although it is typically the case that an upstream branch is a proper (refs/heads/*) branch in the remote repo (which explains why we have not noticed this until now), I think it is _wrong_ of Git to _require_ this when configuring the upstream. Per's setup that triggered this series is described in more detail in patch #4/5 (which introduces a testcase illustrating the breakage), and the actual fix (which simply removes the extra refs/heads/* requirement on the remote ref) is in patch #5/5. The two first patches are unrelated trivial fixes that I encountered while working on this, and patch #3 is a small documentation update suggested by Per. ...Johan Johan Herland (4): t2024: Fix inconsequential typos t3200: Minor fix when preparing for tracking failure Refer to branch.name.remote/merge when documenting --track t3200: Add test demonstrating minor regression in 41c21f2 Per Cederqvist (1): branch.c: Relax unnecessary requirement on upstream's remote ref name Documentation/git-branch.txt | 6 -- branch.c | 3 +-- t/t2024-checkout-dwim.sh | 4 ++-- t/t3200-branch.sh| 37 - 4 files changed, 43 insertions(+), 7 deletions(-) -- 1.8.3.GIT -- 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/5] t3200: Minor fix when preparing for tracking failure
We're testing that trying to --track a ref that is not covered by any remote refspec should fail. For that, we want to have refs/remotes/local/master present, but we also want the remote.local.fetch refspec to NOT match refs/remotes/local/master (so that the tracking setup will fail, as intended). However, when doing git fetch local to ensure the existence of refs/remotes/local/master, we must not already have changed remote.local.fetch so as to cause refs/remotes/local/master not to be fetched. Therefore, set remote.local.fetch to refs/heads/*:refs/remotes/local/* BEFORE we fetch, and then reset it to refs/heads/s:refs/remotes/local/s AFTER we have fetched (but before we test --track). Signed-off-by: Johan Herland jo...@herland.net --- t/t3200-branch.sh | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 44ec6a4..8f6ab8e 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -319,8 +319,9 @@ test_expect_success 'test tracking setup (non-wildcard, matching)' ' test_expect_success 'tracking setup fails on non-matching refspec' ' git config remote.local.url . - git config remote.local.fetch refs/heads/s:refs/remotes/local/s + git config remote.local.fetch refs/heads/*:refs/remotes/local/* (git show-ref -q refs/remotes/local/master || git fetch local) + git config remote.local.fetch refs/heads/s:refs/remotes/local/s test_must_fail git branch --track my5 local/master test_must_fail git config branch.my5.remote test_must_fail git config branch.my5.merge -- 1.8.3.GIT -- 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/5] Refer to branch.name.remote/merge when documenting --track
Make it easier for readers to find the actual config variables that implement the upstream relationship. Suggested-by: Per Cederqvist ced...@opera.com Signed-off-by: Johan Herland jo...@herland.net --- In a private email exchange, Per noted that it was hard for someone reading the git-branch docs to grasp what really happens when you use --track to establish an upstream relationship. This adds a couple of references to the config variables involved, and will hopefully make the upstream relationship a little less magic. ...Johan Documentation/git-branch.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt index b7cb625..311b336 100644 --- a/Documentation/git-branch.txt +++ b/Documentation/git-branch.txt @@ -48,7 +48,8 @@ working tree to it; use git checkout newbranch to switch to the new branch. When a local branch is started off a remote-tracking branch, Git sets up the -branch so that 'git pull' will appropriately merge from +branch (specifically the `branch.name.remote` and `branch.name.merge` +configuration entries) so that 'git pull' will appropriately merge from the remote-tracking branch. This behavior may be changed via the global `branch.autosetupmerge` configuration flag. That setting can be overridden by using the `--track` and `--no-track` options, and @@ -156,7 +157,8 @@ This option is only applicable in non-verbose mode. -t:: --track:: - When creating a new branch, set up configuration to mark the + When creating a new branch, set up `branch.name.remote` and + `branch.name.merge` configuration entries to mark the start-point branch as upstream from the new branch. This configuration will tell git to show the relationship between the two branches in `git status` and `git branch -v`. Furthermore, -- 1.8.3.GIT -- 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 5/5] branch.c: Relax unnecessary requirement on upstream's remote ref name
From: Per Cederqvist ced...@opera.com When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch.name.remote and branch.name.merge. However, if the matching refspec does not have refs/heads/something on the remote side, we end up rejecting the match, and failing the upstream configuration. It could be argued that when we set up an branch's upstream, we want that upstream to also be a proper branch in the remote repo. Although this is typically the common case, there are cases (as demonstrated by the previous patch in this series) where this requirement prevents a useful upstream relationship from being formed. Furthermore: - We have fundamentally no say in how the remote repo have organized its branches. The remote repo may put branches (or branch-like constructs that are insteresting for downstreams to track) outside refs/heads/*. - The user may intentionally want to track a non-branch from a remote repo, by using a branch and configured upstream in the local repo. Relaxing the checking to only require a matching remote/refspec allows the testcase introduced in the previous patch to succeed, and has no negative effect on the rest of the test suite. This patch fixes a behavior (arguably a regression) first introduced in 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*) on 2013-04-21 (released in = v1.8.3.2). Signed-off-by: Johan Herland jo...@herland.net --- FTR, Per made the original fix, and I supplied the commit message. ...Johan branch.c | 3 +-- t/t3200-branch.sh | 2 +- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/branch.c b/branch.c index c5c6984..2d15c19 100644 --- a/branch.c +++ b/branch.c @@ -203,8 +203,7 @@ static int check_tracking_branch(struct remote *remote, void *cb_data) struct refspec query; memset(query, 0, sizeof(struct refspec)); query.dst = tracking_branch; - return !(remote_find_tracking(remote, query) || -prefixcmp(query.src, refs/heads/)); + return !remote_find_tracking(remote, query); } static int validate_remote_tracking_branch(char *ref) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 4031693..f010303 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -871,7 +871,7 @@ test_expect_success '--merged catches invalid object names' ' test_must_fail git branch --merged ' -test_expect_failure 'tracking with unexpected .fetch refspec' ' +test_expect_success 'tracking with unexpected .fetch refspec' ' git init a ( cd a -- 1.8.3.GIT -- 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 4/5] t3200: Add test demonstrating minor regression in 41c21f2
In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact within the domain of a remote, and we then use that information to deduce the upstream configuration (branch.name.remote and branch.name.merge). However, with that change, we also check that - in addition to a matching refspec - the result of mapping the tracking branch through that refspec (i.e. the corresponding ref name in the remote repo) happens to start with refs/heads/. In other words, we require that a tracking branch refers to a _branch_ in the remote repo. Now, consider that you are e.g. setting up an automated building/testing infrastructure for a group of similar source repositories. The build/test infrastructure consists of a central scheduler, and a number of build/test slave machines that perform the actual build/test work. The scheduler monitors the group of similar repos for changes (e.g. with a periodic git fetch), and triggers builds/tests to be run on one or more slaves. Graphically the changes flow between the repos like this: Source #1 ---v Slave #1 / Source #2 - Scheduler - Slave #2 \ Source #3 ---^ Slave #3 ... ... The scheduler maintains a single Git repo with each of the source repos set up as distinct remotes. The slaves also need access to all the changes from all of the source repos, so they pull from the scheduler repo, but using the following custom refspec: remote.origin.fetch = +refs/remotes/*:refs/remotes/* This makes all of the scheduler's remote-tracking branches automatically available as identical remote-tracking branches in each of the slaves. Now, consider what happens if a slave tries to create a local branch with one of the remote-tracking branches as upstream: git branch local_branch --track refs/remotes/source-1/some_branch Git now looks at the configured remotes (in this case there is only origin, pointing to the scheduler's repo) and sees refs/remotes/source-1/some_branch matching origin's refspec. Mapping through that refspec we find that the corresponding remote ref name is refs/remotes/source-1/some_branch. However, since this remote ref name does not start with refs/heads/, we discard it as a suitable upstream, and the whole command fails. This patch adds a testcase demonstrating this failure by creating two source repos (a and b) that are forwarded through a scheduler (c) to a slave repo (d), that then tries create a local branch with an upstream. See the next patch in this series for the exciting conclusion to this story... Reported-by: Per Cederqvist ced...@opera.com Signed-off-by: Johan Herland jo...@herland.net --- I was not sure where to place this, so I tacked it onto the end of t3200. Also, I wouldn't mind dropping the whole build/test infrastructure story from the commit message if the rationale for this kind of setup (and this patch) can be expressed more concisely. ...Johan t/t3200-branch.sh | 34 ++ 1 file changed, 34 insertions(+) diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh index 8f6ab8e..4031693 100755 --- a/t/t3200-branch.sh +++ b/t/t3200-branch.sh @@ -871,4 +871,38 @@ test_expect_success '--merged catches invalid object names' ' test_must_fail git branch --merged ' +test_expect_failure 'tracking with unexpected .fetch refspec' ' + git init a + ( + cd a + test_commit a + ) + git init b + ( + cd b + test_commit b + ) + git init c + ( + cd c + test_commit c + git remote add a ../a + git remote add b ../b + git fetch --all + ) + git init d + ( + cd d + git remote add c ../c + git config remote.c.fetch +refs/remotes/*:refs/remotes/* + git fetch c + git branch --track local/a/master remotes/a/master + test $(git config branch.local/a/master.remote) = c + test $(git config branch.local/a/master.merge) = refs/remotes/a/master + git rev-parse --verify a expect + git rev-parse --verify local/a/master actual + test_cmp expect actual + ) +' + test_done -- 1.8.3.GIT -- 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/5] t2024: Fix inconsequential typos
Signed-off-by: Johan Herland jo...@herland.net --- t/t2024-checkout-dwim.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh index dee55e4..6c78fba 100755 --- a/t/t2024-checkout-dwim.sh +++ b/t/t2024-checkout-dwim.sh @@ -113,9 +113,9 @@ test_expect_success 'setup more remotes with unconventional refspecs' ' cd repo_d test_commit d_master git checkout -b baz - test_commit f_baz + test_commit d_baz git checkout -b eggs - test_commit c_eggs + test_commit d_eggs ) git remote add repo_c repo_c git config remote.repo_c.fetch \ -- 1.8.3.GIT -- 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-gui: Modify push dialog to support Gerrit review
Problem: It is not possible to push for Gerrit review as you will
always try to push to refs/heads/... on the remote.
Changes done:
Add an option to select Gerrit review and a corresponding entry
for a branch name. If this option is selected, push the changes to
refs/for/gerrit-branch/local branch. In this way the local branch
names will be used as topic branches on Gerrit.
---
Hi all,
This is a second attempt to support Gerrit review. It is fully backwards
compatible as the Gerrit option is an addition only. It is also better
than the first approach as it supports pushing more local branches to
Gerrit - each having their own topic branch there.
Further improvement could be to make the Gerrit branch specification a
drop down list, but I would like to have this first simple approach
evaluated first.
BR Joergen
lib/transport.tcl | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/lib/transport.tcl b/lib/transport.tcl
index e5d211e..adf2bbb 100644
--- a/lib/transport.tcl
+++ b/lib/transport.tcl
@@ -61,6 +61,7 @@ proc push_to {remote} {
proc start_push_anywhere_action {w} {
global push_urltype push_remote push_url push_thin push_tags
+ global gerrit_review gerrit_branch
global push_force
global repo_config
@@ -95,7 +96,15 @@ proc start_push_anywhere_action {w} {
set cnt 0
foreach i [$w.source.l curselection] {
set b [$w.source.l get $i]
- lappend cmd refs/heads/$b:refs/heads/$b
+ if {$gerrit_review $gerrit_branch ne {}} {
+ if {$gerrit_branch eq $b} {
+ lappend cmd refs/heads/$b:refs/for/$b
+ } else {
+ lappend cmd
refs/heads/$b:refs/for/$gerrit_branch/$b
+ }
+ } else {
+ lappend cmd refs/heads/$b:refs/heads/$b
+ }
incr cnt
}
if {$cnt == 0} {
@@ -120,6 +129,7 @@ trace add variable push_remote write \
proc do_push_anywhere {} {
global all_remotes current_branch
global push_urltype push_remote push_url push_thin push_tags
+ global gerrit_review gerrit_branch
global push_force use_ttk NS
set w .push_setup
@@ -215,6 +225,24 @@ proc do_push_anywhere {} {
-text [mc Include tags] \
-variable push_tags
grid $w.options.tags -columnspan 2 -sticky w
+ ${NS}::checkbutton $w.options.gerrit \
+ -text [mc Gerrit review. Branch: ] \
+ -variable gerrit_review
+ ${NS}::entry $w.options.gerrit_br \
+ -width 50 \
+ -textvariable gerrit_branch \
+ -validate key \
+ -validatecommand {
+ if {%d == 1 [regexp {\s} %S]} {return 0}
+ if {%d == 1 [string length %S] 0} {
+ set gerrit_review 1
+ }
+ if {[string length %P] == 0} {
+ set gerrit_review 0
+ }
+ return 1
+ }
+ grid $w.options.gerrit $w.options.gerrit_br -sticky we -padx {0 5}
grid columnconfigure $w.options 1 -weight 1
pack $w.options -anchor nw -fill x -pady 5 -padx 5
--
1.7.9.5
--
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: Remote's 'currently active branch' not HEAD?
On Tue, 03 Sep 2013 08:33:39 +, Junio C Hamano wrote: ... Reading the patch series from 2008 again, I do agree with J6t's comment that it should be just a regular capability, I've implemented it as a 'sym=refs/heads/foo' capability. It actually makes the patch series a lot shorter; the only thing I don't get running is the t5601-clone.sh test case. If I run the exact same commands in a shell script they succeed, in t5601-clone.sh the clone step seems to fail, and I have no clue where to look for a clue. Any pointers? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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-svn: Fix termination issues for remote svn connections
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
Uli Heller uli.hel...@daemons-point.com writes:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see https://code.google.com/p/serf/source/detail?r=2146)
.
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too. The change frees the private copy of
the remote access object on termination which prevents the error
from happening.
Note: Since subversion-1.8.0 and later do require serf-1.2.1 or
later,
the core dumps typically do show up when upgrading to a recent
version
of subversion.
Credits: Jonathan Lambrechts for proposing a fix to Ra.pm.
Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and
pointing me to that fix.
---
Thanks. Please sign-off your patch.
I am Cc'ing Kyle McKay who apparently had some experience working
with git-svn with newer svn that can only use serf, hoping that we
can get an independent opinion/test just to be sure. Also Cc'ed is
Eric Wong who has been the official git-svn area expert, but I
understand that Eric hasn't needed to use git-svn for quite a while,
so it is perfectly fine if he does not have any comment on this one.
We may want to find a volunteer to move git svn forward as a new
area expert (aka subsystem maintainer), by the way.
perl/Git/SVN/Ra.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 75ecc42..78dd346 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -32,6 +32,11 @@ BEGIN {
}
}
+END {
+ $RA = undef;
+ $ra_invalid = 1;
+}
+
sub _auth_providers () {
my @rv = (
SVN::Client::get_simple_provider(),
I have not, as of yet, been able to reproduce the problem, so I cannot
verify the solution. Maybe Uli can provide an example of a git-svn
command that demonstrates the failure?
I am running a fresh build of subversion 1.8.3 with serf version 1.3.1
(the most recent serf release).
According to the serf library history, version 1.3.1 of serf was
tagged at revision 2139 from revision 2138, but the serf fix mentioned
above was checked in at revision 2146, so it cannot possibly be in the
serf 1.3.1 release.
I'm using Git built from master (57e4c1783). I see the same behavior
both with and without the SVN/Ra.pm patch (and using both bulk updates
and skelta mode). Does the problem not happen on a git svn clone? I
can force serf back to version 1.2.1 and try that version just to see,
but I would like to have an example of a known failing git svn command
for testing purposes. 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] git-svn: Fix termination issues for remote svn connections
On Fri, September 6, 2013 1:46 pm, Kyle J. McKay wrote:
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
Uli Heller uli.hel...@daemons-point.com writes:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see
https://code.google.com/p/serf/source/detail?r=2146)
.
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too. The change frees the private copy of
the remote access object on termination which prevents the error
from happening.
Note: Since subversion-1.8.0 and later do require serf-1.2.1 or
later,
the core dumps typically do show up when upgrading to a recent
version
of subversion.
Credits: Jonathan Lambrechts for proposing a fix to Ra.pm.
Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and
pointing me to that fix.
---
Thanks. Please sign-off your patch.
I am Cc'ing Kyle McKay who apparently had some experience working
with git-svn with newer svn that can only use serf, hoping that we
can get an independent opinion/test just to be sure. Also Cc'ed is
Eric Wong who has been the official git-svn area expert, but I
understand that Eric hasn't needed to use git-svn for quite a while,
so it is perfectly fine if he does not have any comment on this one.
We may want to find a volunteer to move git svn forward as a new
area expert (aka subsystem maintainer), by the way.
perl/Git/SVN/Ra.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 75ecc42..78dd346 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -32,6 +32,11 @@ BEGIN {
}
}
+END {
+ $RA = undef;
+ $ra_invalid = 1;
+}
+
sub _auth_providers () {
my @rv = (
SVN::Client::get_simple_provider(),
I have not, as of yet, been able to reproduce the problem, so I cannot
verify the solution. Maybe Uli can provide an example of a git-svn
command that demonstrates the failure?
I am running a fresh build of subversion 1.8.3 with serf version 1.3.1
(the most recent serf release).
According to the serf library history, version 1.3.1 of serf was
tagged at revision 2139 from revision 2138, but the serf fix mentioned
above was checked in at revision 2146, so it cannot possibly be in the
serf 1.3.1 release.
I'm using Git built from master (57e4c1783). I see the same behavior
both with and without the SVN/Ra.pm patch (and using both bulk updates
and skelta mode). Does the problem not happen on a git svn clone? I
can force serf back to version 1.2.1 and try that version just to see,
but I would like to have an example of a known failing git svn command
for testing purposes. Thanks.
I think this command should produce the error:
git svn clone --stdlayout https://github.com/uli-heller/uli-javawrapper
You can use any other svn repo as well, you only have to specify an HTTPS
url.
[Yes, I know you typically don't clone github via git svn]
I'll do some more tests using git HEAD and serf 1.3.1 when I'm back home.
Thanks + best regards, Uli
--
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-svn: Fix termination issues for remote svn connections
On Sep 6, 2013, at 05:06, Uli Heller wrote: I'm using Git built from master (57e4c1783). I see the same behavior both with and without the SVN/Ra.pm patch (and using both bulk updates and skelta mode). Does the problem not happen on a git svn clone? I can force serf back to version 1.2.1 and try that version just to see, but I would like to have an example of a known failing git svn command for testing purposes. Thanks. I think this command should produce the error: git svn clone --stdlayout https://github.com/uli-heller/uli-javawrapper You can use any other svn repo as well, you only have to specify an HTTPS url. Yes, that does it. Interesting that cloning from https://github.com/uli-heller/uli-javawrapper core dumps while cloning from http://github.com/uli-heller/uli-javawrapper does not even though the latter redirects to https://github.com/uli-heller/uli-javawrapper . In any case, I can now reproduce the problem (serf 1.3.1 still breaks since it does not yet contain the fix and it is the most recent serf release available). And the Git/SVN/Ra.pm fix does eliminate the problem for me (both with bulk updates and with skelta updates -- the crash occurs with either). -- 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-svn: Fix termination issues for remote svn connections
On Sep 5, 2013, at 11:48, Junio C Hamano wrote:
I am Cc'ing Kyle McKay who apparently had some experience working
with git-svn with newer svn that can only use serf, hoping that we
can get an independent opinion/test just to be sure.
On Sep 3, 2013, at 00:35, Uli Heller wrote:
When using git-svn in combination with serf-1.2.1 core dumps are
created on termination. This is caused by a bug in serf, a fix for
the bug exists (see https://code.google.com/p/serf/source/detail?r=2146)
.
Nevertheless, I think it makes sense to fix the issue within the
git perl module Ra.pm, too. The change frees the private copy of
the remote access object on termination which prevents the error
from happening.
Note: Since subversion-1.8.0 and later do require serf-1.2.1 or later,
the core dumps typically do show up when upgrading to a recent version
of subversion.
Credits: Jonathan Lambrechts for proposing a fix to Ra.pm.
Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and
pointing me to that fix.
---
In addition to the needed 'Signed-off-by:' a mention should be made
here of the need to use 'https:' to reproduce the problem.
perl/Git/SVN/Ra.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 75ecc42..78dd346 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -32,6 +32,11 @@ BEGIN {
}
}
+END {
+ $RA = undef;
+ $ra_invalid = 1;
+}
+
sub _auth_providers () {
my @rv = (
SVN::Client::get_simple_provider(),
--
1.8.4
Tested-by: Kyle J. McKay mack...@gmail.com
I was able to reproduce the core dumps using subversion 1.8.3 (the
most recent subversion release) with serf 1.3.1 (the most recent serf
release) and verify that this patch eliminates the core dump at git-
svn termination time.
--
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: Remote's 'currently active branch' not HEAD?
On Fri, 06 Sep 2013 13:41:30 +, Andreas Krey wrote: ... If I run the exact same commands in a shell script they succeed, in t5601-clone.sh the clone step seems to fail, and I have no clue where to look for a clue. Oh, never mind. --verbose shows that the test is borked; it tries a checkout into an already-existing dir. Patch coming up soon. Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 -- 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-svn: Fix termination issues for remote svn connections
On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote: On Sep 6, 2013, at 05:06, Uli Heller wrote: I'm using Git built from master (57e4c1783). I see the same behavior both with and without the SVN/Ra.pm patch (and using both bulk updates and skelta mode). Does the problem not happen on a git svn clone? I can force serf back to version 1.2.1 and try that version just to see, but I would like to have an example of a known failing git svn command for testing purposes. Thanks. I think this command should produce the error: git svn clone --stdlayout https://github.com/uli-heller/uli-javawrapper You can use any other svn repo as well, you only have to specify an HTTPS url. Yes, that does it. Interesting that cloning from https://github.com/uli-heller/uli-javawrapper core dumps while cloning from http://github.com/uli-heller/uli-javawrapper does not even though the latter redirects to https://github.com/uli-heller/uli-javawrapper . In any case, I can now reproduce the problem (serf 1.3.1 still breaks since it does not yet contain the fix and it is the most recent serf release available). And the Git/SVN/Ra.pm fix does eliminate the problem for me (both with bulk updates and with skelta updates -- the crash occurs with either). Great. So I don't have to run any more tests ;) What shall I do next? Add some inline comments to the patch? --- Best regards, Uli. -- 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] Document pack v4 format
On Fri, 6 Sep 2013, Duy Nguyen wrote: On Thu, Sep 5, 2013 at 11:52 PM, Duy Nguyen pclo...@gmail.com wrote: On Thu, Sep 5, 2013 at 12:39 PM, Nicolas Pitre n...@fluxnic.net wrote: Now the pack index v3 probably needs to be improved a little, again to accommodate completion of thin packs. Given that the main SHA1 table is now in the main pack file, it should be possible to still carry a small SHA1 table in the index file that corresponds to the appended objects only. This means that a SHA1 search will have to first use the main SHA1 table in the pack file as it is done now, and if not found then use the SHA1 table in the index file if it exists. And of course nth_packed_object_sha1() will have to be adjusted accordingly. What if the sender prepares the sha-1 table to contain missing objects in advance? The sender should know what base objects are missing. Then we only need to append objects at the receiving end and verify that all new objects are also present in the sha-1 table. One minor detail to sort out: the size of sha-1 table. Previously it's the number of objects in the pack. Now it's not true because the table may have more entries. So how should we record the table size? We could use null sha-1 as the end of table marker. Or we could make pack-objects to write nr_objects as the number of entries _after_ pack completion, not the true number of objects in thin pack. I like the latter (no more rehashing the entire pack after completion) but then we need a cue to know that we have reached the end of the pack.. See the amendment I made to your documentation patch. I opted for the later. To mark the end of the transmitted objects a zero byte (object type 0) is used. Nicolas -- 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: coming from git, understanding mercurial branching
On 2013-09-06 12:39, Tay Ray Chuan wrote: First: recognize Mercurial's branches are entirely different beasts from Git's. They just happen to be given a same sequence of characters, b-r-a-n-c-h. The similarities end there! Yeah, I'm trying to create a mental map between what Git means by branching, and what Mercurial means by branching. As you say, they seem to be entirely different beasts. often the docs suggest cloning instead of branching; Are you referring to this? $ hg clone https://... master $ cd master # hack... $ cd .. $ hg clone https://... fix1 Usually I see this written as $ cd .. $ hg clone master fix1 but otherwise, yes. $ cd fix1 # hack... $ cd../master $ hg pull ../fix1 $ hg merge ... In git, you would have your master branch, checkout -b fix1, then merge them back to master when you're done. The above describes how one would do this in mercurial. Mercurial has this cloning-branch thing, a branch command, and something called bookmarks which all seem to have different behaviors (and corresponding reasons to choose them) and yet all be loosely referred to as branching. Cloning litters the drive with duplicate checkouts (even if they use hard-linking for the repo behind the scenes, there's still a lot of time spent writing. The git equiv of this hg suite would be almost identical, cloning a local checkout); the 2nd and 3rd are more branch-related and what I'm trying to grok. -tkc -- 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 v3] Document pack v4 format
On Fri, 6 Sep 2013, Duy Nguyen wrote: On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote: Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com --- Should be up to date with Nico's latest implementation and also cover additions to the format that everybody seems to agree on: - new types for canonical trees and commits - sha-1 table covering missing objects in thin packs Great! I've merged this into my branch with the following amendment: I'd like to propose another change in the format to basically limit the use of sha1ref format \0SHA-1 to tree entries only. All forms of deltas must have non-zero sha1 index (i.e. reference to SHA-1 table). It will simplify handling code, and I think it makes sense too Why? This is still some artificial limitation and I tend not to like them. Simplifying handling code is not a good enough reason on its own, especially if it reduce flexibility for possible future layout optimizations. In what way is the code more difficult? Nicolas
Re: [PATCH v3] Document pack v4 format
On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Duy Nguyen wrote: On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote: Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com --- Should be up to date with Nico's latest implementation and also cover additions to the format that everybody seems to agree on: - new types for canonical trees and commits - sha-1 table covering missing objects in thin packs Great! I've merged this into my branch with the following amendment: I'd like to propose another change in the format to basically limit the use of sha1ref format \0SHA-1 to tree entries only. All forms of deltas must have non-zero sha1 index (i.e. reference to SHA-1 table). It will simplify handling code, and I think it makes sense too Why? This is still some artificial limitation and I tend not to like them. Simplifying handling code is not a good enough reason on its own, especially if it reduce flexibility for possible future layout optimizations. In what way is the code more difficult? That'll be two ways of linking to another in-pack object. The linked object must be in the pack anyway, its sha-1 should be present in the sha-1 table. \0sha1 is a longer encoding for nothing. If the linked sha1 is not in the pack (similar to the old ref-delta), it makes the pack depend on another one, which is what we've been avoding. In your code you reject sha1ref starting with zero too (sha1_file.c::get_base_delta and packv4-parse.c::decode_entries) -- 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: coming from git, understanding mercurial branching
On Thu, 5 Sep 2013 21:27:14 -0500 Tim Chase g...@tim.thechases.com wrote: [...] Do any git users here have good understanding Mercurial branches for the git user resources they've found helpful when working with Mercurial? Preferably a for dummies resource with illustrations comparison charts so I can see the big picture. I found this guide [1] very useful back in the time I tried to grok Mercurial. 1. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ -- 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: Officially start moving to the term 'staging area'
On Wed, Sep 4, 2013 at 2:08 PM, William Swanson swanson...@gmail.com wrote: On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras felipe.contre...@gmail.com wrote: It has been discussed many times in the past that 'index' is not an appropriate description for what the high-level user does with it, and it has been agreed that 'staging area' is the best term. I realize Git is not a democracy, but if the vote of a humble user counts for anything, I agree that index is a terrible name. +1 for staging area I was very excited when Felipe first started this thread, since I thought Git might finally fix one of it's biggest long-standing usability problems. the same feeling. -- 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: What's cooking in git.git (Sep 2013, #01; Tue, 3)
Jiang Xin worldhello@gmail.com writes: 2013/9/4 Junio C Hamano gits...@pobox.com: * jx/branch-vv-always-compare-with-upstream (2013-08-26) 2 commits - status: always show tracking branch even no change - branch: report invalid tracking branch as gone git branch -v -v (and git status) did not distinguish among a branch that does not build on any other branch, a branch that is in sync with the branch it builds on, and a branch that is configured to build on some other branch that no longer exists. Am I waiting for another reroll? No more reroll if no more votes for “absent vs gone, and in sync with vs up-to-date with. I re-read the thread and the way I read both of these choices is that they were merely this other word is also possible, may be better, but may be not. and not meant as strong recommendations. Since that seems to be the only remaining issue, let's unchock and merge the topic to 'next'. Thanks. Currently, we choose gone” and up-to-date with, such as: $ git branch -v -v mastere67ac84 initial * topic 3fc0f2a [topicbase: gone] topic $ git status # On branch topic # Your branch is based on 'topicbase', but the upstream is gone. # (use git branch --unset-upstream to fixup) ... $ git status # On branch feature1 # Your branch is up-to-date with 'github/feature1'. ... -- 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 V3] check-ignore: Add option to ignore index contents
Dave Williams d...@opensourcesolutions.co.uk writes: On 15:27, Thu 05 Sep 13, Junio C Hamano wrote: Now the long option name is --no-index, it makes me wonder if -i is a good synonym for it, and the longer I stare at it, the more certain I become convinced that it is a bad choice. I had originally called it --ignore-index at which point -i made more sense! I know, but with --no-index it no longer does. -- 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] upload-pack: send the HEAD information
From: Junio C Hamano gits...@pobox.com
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=target.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
upload-pack.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 127e59a..390d1ec 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -745,13 +745,17 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
if (mark_our_ref(refname, sha1, flag, cb_data))
return 0;
- if (capabilities)
- packet_write(1, %s %s%c%s%s%s agent=%s\n,
+ if (capabilities) {
+ unsigned char dummy[20];
+ const char *target = resolve_ref_unsafe(HEAD, dummy, 0, NULL);
+ packet_write(1, %s %s%c%s%s%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0, capabilities,
allow_tip_sha1_in_want ? allow-tip-sha1-in-want
: ,
stateless_rpc ? no-done : ,
+target ? symref= : , target ? target : 0,
git_user_agent_sanitized());
+ }
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
--
1.8.3.1.485.g9704416.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 0/3] Unconfuse git clone when two branches at are HEAD.
Ok, here are some patches that make git actually check out the current remote branch when cloning. Up to now this failed when there were two branches that pointed to the HEAD commit of the remote repo, and git clone would sometimes choose the wrong one as the HEAD ref isn't transmitted in all transport. Stuff the HEAD ref into the capability list (assuming refs are clean enough to do that w/o escaping), and read them out on the other side. All other things were thankfully already in place. Two of the patches have Junio in the From as they are essentially his. Andreas -- 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] connect.c: save symref info from server capabilities
Signed-off-by: Andreas Krey a.k...@gmx.de
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
for (;;) {
struct ref *ref;
unsigned char old_sha1[20];
- char *name;
- int len, name_len;
+ char *name, *symref;
+ int len, name_len, symref_len;
char *buffer = packet_buffer;
len = packet_read(in, src_buf, src_len,
@@ -94,9 +94,12 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
name = buffer + 41;
name_len = strlen(name);
+ symref = 0;
if (len != name_len + 41) {
free(server_capabilities);
server_capabilities = xstrdup(name + name_len + 1);
+ symref = parse_feature_value(server_capabilities,
+symref, symref_len);
}
if (extra_have
@@ -108,6 +111,10 @@ struct ref **get_remote_heads(int in, char *src_buf,
size_t src_len,
if (!check_ref(name, name_len, flags))
continue;
ref = alloc_ref(buffer + 41);
+ if (symref) {
+ ref-symref = xcalloc(symref_len + 1, 1);
+ strncpy(ref-symref, symref, symref_len);
+ }
hashcpy(ref-old_sha1, old_sha1);
*list = ref;
list = ref-next;
--
1.8.3.1.485.g9704416.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 3/3] clone: test the new HEAD detection logic
From: Junio C Hamano gits...@pobox.com Signed-off-by: Junio C Hamano gits...@pobox.com Signed-off-by: Andreas Krey a.k...@gmx.de --- t/t5601-clone.sh | 11 +++ 1 file changed, 11 insertions(+) diff --git a/t/t5601-clone.sh b/t/t5601-clone.sh index 0629149..ccda6df 100755 --- a/t/t5601-clone.sh +++ b/t/t5601-clone.sh @@ -285,4 +285,15 @@ test_expect_success NOT_MINGW,NOT_CYGWIN 'clone local path foo:bar' ' git clone ./foo:bar foobar ' +test_expect_success 'clone from a repository with two identical branches' ' + + ( + cd src + git checkout -b another master + ) + git clone src target-11 + test z$( cd target-11 git symbolic-ref HEAD ) = zrefs/heads/another + +' + test_done -- 1.8.3.1.485.g9704416.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: [PATCH v3] Document pack v4 format
On Fri, 6 Sep 2013, Duy Nguyen wrote: On Fri, Sep 6, 2013 at 8:25 PM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Duy Nguyen wrote: On Fri, Sep 6, 2013 at 10:23 AM, Nicolas Pitre n...@fluxnic.net wrote: On Fri, 6 Sep 2013, Nguyn Thái Ng÷c Duy wrote: Signed-off-by: Nguyn Thái Ng÷c Duy pclo...@gmail.com --- Should be up to date with Nico's latest implementation and also cover additions to the format that everybody seems to agree on: - new types for canonical trees and commits - sha-1 table covering missing objects in thin packs Great! I've merged this into my branch with the following amendment: I'd like to propose another change in the format to basically limit the use of sha1ref format \0SHA-1 to tree entries only. All forms of deltas must have non-zero sha1 index (i.e. reference to SHA-1 table). It will simplify handling code, and I think it makes sense too Why? This is still some artificial limitation and I tend not to like them. Simplifying handling code is not a good enough reason on its own, especially if it reduce flexibility for possible future layout optimizations. In what way is the code more difficult? That'll be two ways of linking to another in-pack object. The linked object must be in the pack anyway, its sha-1 should be present in the sha-1 table. \0sha1 is a longer encoding for nothing. If the linked sha1 is not in the pack (similar to the old ref-delta), it makes the pack depend on another one, which is what we've been avoding. OK. Let's say that if the needed SHA1 exists in the table then the sha1ref should use an index into that table. That's a recommendation we can make, just like we suggest to have the ident/path tables sorted by usage frequency. But even if index 0 with a SHA1 is used inline for an object in the same pack, it is still theoretically a valid pack even if somewhat wasteful. Maybe some tools in the future will benefit from this flexibility to simplify their implementation. You mention that only tree objects should use this encoding, but commits should be allowed to use it as well. Suppose that a commit reverts some changes to a pre-existing tree state. That tree might already be in another pack and we shouldn't have to copy it into the current pack. Same goes for commit parents. Etc. In your code you reject sha1ref starting with zero too (sha1_file.c::get_base_delta and packv4-parse.c::decode_entries) Yeah... because I wrote the minimum code to make it work with the current encoder. But the decoder could be more lenient than that. It's just a matter of adding a call to find_pack_entry_one() when the sha1ref index is 0. Nicolas
Re: [PATCH v4 0/5] Disable git status comment prefix
Jeff King p...@peff.net writes: # and have 472 and 59 different commits each, respectively. # # Untracked files: [...] and have 472 and 59 different commits each, respectively. Untracked files: Indeed, I forgot the else branch in wt_status_print_tracking: if (s-display_comment_char) color_fprintf_ln(s-fp, color(WT_STATUS_HEADER, s), %c, comment_line_char); else fprintf_ln(s-fp, ); -- 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: [PATCH] git-svn: Fix termination issues for remote svn connections
Uli Heller uli.hel...@daemons-point.com writes:
On Fri, September 6, 2013 2:44 pm, Kyle J. McKay wrote:
...
In any case, I can now reproduce the problem (serf 1.3.1 still breaks
since it does not yet contain the fix and it is the most recent serf
release available).
And the Git/SVN/Ra.pm fix does eliminate the problem for me (both with
bulk updates and with skelta updates -- the crash occurs with either).
Great. So I don't have to run any more tests ;)
What shall I do next? Add some inline comments to the patch?
Something like this?
-- 8 --
From: Uli Heller uli.hel...@daemons-point.com
Subject: [PATCH] git-svn: fix termination issues for remote svn connections
git-svn used in combination with serf to talk to svn repository
served over HTTPS dumps core on termination.
This is caused by a bug in serf, and the most recent serf release
1.3.1 still exhibits the problem; a fix for the bug exists (see
https://code.google.com/p/serf/source/detail?r=2146).
Until the bug is fixed, work around the issue within the git perl
module Ra.pm by freeing the private copy of the remote access object
on termination, which seems to be sufficient to prevent the error
from happening.
Note: Since subversion-1.8.0 and later do require serf-1.2.1 or
later, this issue typically shows up when upgrading to a recent
version of subversion.
Credits go to Jonathan Lambrechts for proposing a fix to Ra.pm,
Evgeny Kotkov and Ivan Zhakov for fixing the issue in serf and
pointing me to that fix.
Signed-off-by: Uli Heller uli.hel...@daemons-point.com
Tested-by: Kyle J. McKay mack...@gmail.com
---
perl/Git/SVN/Ra.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN/Ra.pm b/perl/Git/SVN/Ra.pm
index 75ecc42..78dd346 100644
--- a/perl/Git/SVN/Ra.pm
+++ b/perl/Git/SVN/Ra.pm
@@ -32,6 +32,14 @@ BEGIN {
}
}
+# serf has a bug that leads to a coredump upon termination if the
+# remote access object is left around (not fixed yet in serf 1.3.1).
+# Explicitly free it to work around the issue.
+END {
+ $RA = undef;
+ $ra_invalid = 1;
+}
+
sub _auth_providers () {
my @rv = (
SVN::Client::get_simple_provider(),
--
1.8.4-431-g94f3a6b
--
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: coming from git, understanding mercurial branching
From: Konstantin Khomoutov flatw...@users.sourceforge.net To: Tim Chase g...@tim.thechases.com On Thu, 5 Sep 2013 21:27:14 -0500 Tim Chase g...@tim.thechases.com wrote: [...] Do any git users here have good understanding Mercurial branches for the git user resources they've found helpful when working with Mercurial? Preferably a for dummies resource with illustrations comparison charts so I can see the big picture. I found this guide [1] very useful back in the time I tried to grok Mercurial. 1. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ -- Tim, Another recent blog is http://felipec.org/2013/08/27/analysis-of-hg-and-git-branches/ by Felipe Contreras who wrote Git's official GitMercurial bridge; git-remote-hg Philip -- 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/5] branch: Fix --track on a remote-tracking non-branch
Johan Herland jo...@herland.net writes: However, in addition to requiring a matching remote/refspec, I also (for reasons that are still unclear to me) added a requirement that the resulting remote ref name (to be stored into branch.name.merge) must start with refs/heads/ (see the last line of branch.c:check_tracking_branch()). Although it is typically the case that an upstream branch is a proper (refs/heads/*) branch in the remote repo (which explains why we have not noticed this until now), I think it is _wrong_ of Git to _require_ this when configuring the upstream. Yeah, I agree. -- 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: Officially start moving to the term 'staging area'
On 6 September 2013 08:45, Ping Yin pkufra...@gmail.com wrote: On Wed, Sep 4, 2013 at 2:08 PM, William Swanson swanson...@gmail.com wrote: On Thu, Aug 29, 2013 at 11:01 AM, Felipe Contreras felipe.contre...@gmail.com wrote: It has been discussed many times in the past that 'index' is not an appropriate description for what the high-level user does with it, and it has been agreed that 'staging area' is the best term. I realize Git is not a democracy, but if the vote of a humble user counts for anything, I agree that index is a terrible name. +1 for staging area As yet another just a user, I'd like to add my enthusiastic support for to stage and staging area. I'm guessing that a lot of Git devs/long time users are simply so used to its interface that they may not see its sharp corners any more. :-) That's quite natural and bound to happen to anyone who works with a particular tool for a long time. Still, (e.g.) git add -A removing files (as useful as that is) is just weird. And, in general, the user should not need to know how Git is implemented. I was very excited when Felipe first started this thread, since I thought Git might finally fix one of it's biggest long-standing usability problems. the same feeling. Ditto. :-) -- 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 0/5] Disable git status comment prefix
Jeff King wrote: On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote: I'm fine with any name actually (since it is enabled by default, people don't need to know the name to benefit from the new output). Maybe status.displayCommentPrefix was the best name after all. FWIW, I had the same thought as Junio. I much prefer something like status.displayCommentPrefix for clarity and future-proofing. Sounds fine, but I don't understand why we'd want this to be an option with a future in the first place. Why not just fix the remaining bugs before merging to master and make it unconditional? [...] after: On branch private Your branch and 'origin/next' have diverged, and have 472 and 59 different commits each, respectively. Untracked files: t/foo test-obj-pool test-string-pool test-treap test-url-normalize nothing added to commit but untracked files present The blank before Untracked files was dropped (was this intentional? I didn't see any note of it in the discussion), That's a bug. and the bottom nothing added line butts against the untracked list more obviously, because they now all have the same comment indentation. I wonder if it would look a little nicer as: On branch private Your branch and 'origin/next' have diverged, and have 472 and 59 different commits each, respectively. Untracked files: t/foo test-obj-pool test-string-pool test-treap test-url-normalize nothing added to commit but untracked files present The added blank line before nothing added sounds like a good idea. Thanks, Jonathan -- 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/3] Unconfuse git clone when two branches at are HEAD.
From: Andreas Krey a.k...@gmx.de Ok, here are some patches that make git actually check out the current remote branch when cloning. Up to now this failed when there were two branches that pointed to the HEAD commit of the remote repo, and git clone would sometimes choose the wrong one as the HEAD ref isn't transmitted in all transport. Stuff the HEAD ref into the capability list (assuming refs are clean enough to do that w/o escaping), and read them out on the other side. All other things were thankfully already in place. Two of the patches have Junio in the From as they are essentially his. Andreas -- Does this have any impact on the alleged bug in `git bundle --all` (which can then be cloned from) where the current HEAD ref wasn't included in the bundle? Or am I mis-remembering? Philip -- 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: A naive proposal for preventing loose object explosions
mf...@codeaurora.org writes: Object lookups should likely not get any slower than if repack were not run, and the extra new pack might actually help find some objects quicker. In general, having an extra pack, only to keep objects that you know are available in other packs, will make _all_ object accesses, not just the ones that are contained in that extra pack, slower. Instead of mmapping all the .idx files for all the available packfiles, we could build a table that records, for each packed object, from which packfile at what offset the data is available to optimize the access, but obviously building that in-core table will take time, so it may not be a good trade-off to do so at runtime (a precomputed super-.idx that we can mmap at runtime might be a good way forward if that turns out to be the case). Does this sound like it would work? Sorry, but it is unclear what problem you are trying to solve. Is it that you do not like that repack -A ejects unreferenced objects and makes it loose, which you may have many? The loosen_unused_packed_objects() function used by repack -A calls the force_object_loose() function (actually, it is the sole caller of the function). If you tweak the latter to stream to a single new graveyard packfile and mark it as kept until expiry, would it solve the issue the same way but with much smaller impact? There already is an infrastructure available to open a single output packfile and send multiple objects to it in bulk-checkin.c, and I am wondering if you can take advantage of the framework. The existing interface to it assumes that the object data is coming from a file descriptor (the interface was built to support bulk-checkin of many objects in an empty repository), and it needs refactoring to allow stream_to_pack() to take different kind of data sources in the form of stateful callback function, though. -- 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 0/5] Disable git status comment prefix
Jonathan Nieder jrnie...@gmail.com writes: Jeff King wrote: On Thu, Sep 05, 2013 at 09:36:47PM +0200, Matthieu Moy wrote: I'm fine with any name actually (since it is enabled by default, people don't need to know the name to benefit from the new output). Maybe status.displayCommentPrefix was the best name after all. FWIW, I had the same thought as Junio. I much prefer something like status.displayCommentPrefix for clarity and future-proofing. Sounds fine, but I don't understand why we'd want this to be an option with a future in the first place. Why not just fix the remaining bugs before merging to master and make it unconditional? I think some old-time users may appreciate to have a backward-compatibility option. It doesn't cost much for us, as we need the variable internally (to use the prefix in COMMIT_EDITMSG, and not on stdout), and it actually makes it easier to test. and the bottom nothing added line butts against the untracked list more obviously, because they now all have the same comment indentation. I wonder if it would look a little nicer as: On branch private Your branch and 'origin/next' have diverged, and have 472 and 59 different commits each, respectively. Untracked files: t/foo test-obj-pool test-string-pool test-treap test-url-normalize nothing added to commit but untracked files present The added blank line before nothing added sounds like a good idea. I won't change the header part in this topic (no time, sorry), but the missing newline before nothing added actually sounds like a bug, as there is normally a newline after each list of file in `git status`, except untracked and ignored. I'll fix it as a separate patch in the next round. -- 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: [PATCH 1/5] t2024: Fix inconsequential typos
Johan Herland jo...@herland.net writes: Signed-off-by: Johan Herland jo...@herland.net --- t/t2024-checkout-dwim.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh index dee55e4..6c78fba 100755 --- a/t/t2024-checkout-dwim.sh +++ b/t/t2024-checkout-dwim.sh @@ -113,9 +113,9 @@ test_expect_success 'setup more remotes with unconventional refspecs' ' cd repo_d test_commit d_master git checkout -b baz - test_commit f_baz + test_commit d_baz Not limited to this hunk but there seems to be a breakage in the chain here. git checkout -b eggs - test_commit c_eggs + test_commit d_eggs ) git remote add repo_c repo_c git config remote.repo_c.fetch \ -- 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 3/6] submodule summary: ignore --for-status option
The --for-status option was an undocumented option used only by
wt-status.c, which inserted a header and commented out the output. We can
achieve the same result within wt-status.c, without polluting the
submodule command-line options.
This will make it easier to disable the comments from wt-status.c later.
The --for-status is kept so that another topic in flight
(bc/submodule-status-ignored) can continue relying on it, although it is
currently a no-op.
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
git-submodule.sh | 13 +
t/t7401-submodule-summary.sh | 12 +---
wt-status.c | 27 ++-
3 files changed, 32 insertions(+), 20 deletions(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2979197..c17bef1 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -1149,18 +1149,7 @@ cmd_summary() {
echo
fi
echo
- done |
- if test -n $for_status; then
- if [ -n $files ]; then
- gettextln Submodules changed but not updated: | git
stripspace -c
- else
- gettextln Submodule changes to be committed: | git
stripspace -c
- fi
- printf \n | git stripspace -c
- git stripspace -c
- else
- cat
- fi
+ done
}
#
# List all submodules, prefixed with:
diff --git a/t/t7401-submodule-summary.sh b/t/t7401-submodule-summary.sh
index ac2434c..5a6d6d6 100755
--- a/t/t7401-submodule-summary.sh
+++ b/t/t7401-submodule-summary.sh
@@ -265,13 +265,11 @@ EOF
test_expect_success '--for-status'
git submodule summary --for-status HEAD^ actual
test_i18ncmp actual - EOF
-# Submodule changes to be committed:
-#
-# * sm1 $head6...000:
-#
-# * sm2 000...$head7 (2):
-#Add foo9
-#
+* sm1 $head6...000:
+
+* sm2 000...$head7 (2):
+ Add foo9
+
EOF
diff --git a/wt-status.c b/wt-status.c
index 958a53c..853813f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -665,6 +665,10 @@ static void wt_status_print_submodule_summary(struct
wt_status *s, int uncommitt
char index[PATH_MAX];
const char *env[] = { NULL, NULL };
struct argv_array argv = ARGV_ARRAY_INIT;
+ struct strbuf cmd_stdout = STRBUF_INIT;
+ struct strbuf summary = STRBUF_INIT;
+ char *summary_content;
+ size_t len;
sprintf(summary_limit, %d, s-submodule_summary);
snprintf(index, sizeof(index), GIT_INDEX_FILE=%s, s-index_file);
@@ -685,9 +689,30 @@ static void wt_status_print_submodule_summary(struct
wt_status *s, int uncommitt
sm_summary.git_cmd = 1;
sm_summary.no_stdin = 1;
fflush(s-fp);
- sm_summary.out = dup(fileno(s-fp));/* run_command closes it */
+ sm_summary.out = -1;
+
run_command(sm_summary);
argv_array_clear(argv);
+
+ len = strbuf_read(cmd_stdout, sm_summary.out, 1024);
+
+ /* prepend header, only if there's an actual output */
+ if (len) {
+ if (uncommitted)
+ strbuf_addstr(summary, _(Submodules changed but not
updated:));
+ else
+ strbuf_addstr(summary, _(Submodule changes to be
committed:));
+ strbuf_addstr(summary, \n\n);
+ }
+ strbuf_addbuf(summary, cmd_stdout);
+ strbuf_release(cmd_stdout);
+
+ summary_content = strbuf_detach(summary, len);
+ strbuf_add_commented_lines(summary, summary_content, len);
+ free(summary_content);
+
+ fputs(summary.buf, s-fp);
+ strbuf_release(summary);
}
static void wt_status_print_other(struct wt_status *s,
--
1.8.4.5.g8688bea
--
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 1/6] builtin/stripspace.c: fix broken indentation
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
builtin/stripspace.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/builtin/stripspace.c b/builtin/stripspace.c
index e981dfb..1259ed7 100644
--- a/builtin/stripspace.c
+++ b/builtin/stripspace.c
@@ -89,11 +89,11 @@ int cmd_stripspace(int argc, const char **argv, const char
*prefix)
if (argc == 2) {
if (!strcmp(argv[1], -s) ||
- !strcmp(argv[1], --strip-comments)) {
-strip_comments = 1;
+ !strcmp(argv[1], --strip-comments)) {
+ strip_comments = 1;
} else if (!strcmp(argv[1], -c) ||
-!strcmp(argv[1], --comment-lines)) {
-mode = COMMENT_LINES;
+ !strcmp(argv[1], --comment-lines)) {
+ mode = COMMENT_LINES;
} else {
mode = INVAL;
}
--
1.8.4.5.g8688bea
--
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 6/6] status: add missing blank line after list of other files
List of files in other sections (Changes to be committed, ...) end with a blank line. It is not the case with the Untracked files and Ignored files sections. The issue become particularly visible after the #-prefix removal, as the last line (e.g. nothing added to commit but untracked files present) seems mixed with the untracked files. Signed-off-by: Matthieu Moy matthieu@imag.fr --- t/t7508-status.sh | 21 + wt-status.c | 4 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index d0444d3..9bf9701 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -84,6 +84,7 @@ test_expect_success 'status --column' ' # # dir1/untracked dir2/untracked output # dir2/modified expect untracked +# EOF COLUMNS=50 git -c status.displayCommentPrefix=true status --column=column dense output test_i18ncmp expect output @@ -117,6 +118,7 @@ cat expect \EOF # expect # output # untracked +# EOF test_expect_success 'status with status.displayCommentPrefix=true' ' @@ -167,6 +169,7 @@ Untracked files: expect output untracked + EOF test_expect_success 'status (advice.statusHints false)' ' @@ -241,6 +244,7 @@ Untracked files: (use git add file... to include in what will be committed) dir2/modified + Ignored files: (use git add -f file... to include in what will be committed) @@ -250,6 +254,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -308,6 +313,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -430,6 +436,7 @@ Untracked files: expect output untracked + EOF git status -unormal output test_i18ncmp expect output @@ -488,6 +495,7 @@ Untracked files: expect output untracked + EOF git status -uall output test_i18ncmp expect output @@ -548,6 +556,7 @@ Untracked files: ../expect ../output ../untracked + EOF (cd dir1 git status) output test_i18ncmp expect output @@ -618,6 +627,7 @@ Untracked files: BLUEexpectRESET BLUEoutputRESET BLUEuntrackedRESET + EOF test_config color.ui always git status | test_decode_color output @@ -747,6 +757,7 @@ Untracked files: expect output untracked + EOF test_config status.relativePaths false (cd dir1 git status) output @@ -789,6 +800,7 @@ Untracked files: expect output untracked + EOF git commit --dry-run dir1/modified output test_i18ncmp expect output @@ -838,6 +850,7 @@ Untracked files: expect output untracked + EOF git status output test_i18ncmp expect output @@ -902,6 +915,7 @@ Untracked files: expect output untracked + EOF git config status.submodulesummary 10 git status output @@ -952,6 +966,7 @@ Untracked files: expect output untracked + no changes added to commit (use git add and/or git commit -a) EOF git commit -m commit submodule @@ -1012,6 +1027,7 @@ Untracked files: expect output untracked + EOF git config status.submodulesummary 10 git commit --dry-run --amend output @@ -1066,6 +1082,7 @@ Untracked files: expect output untracked + EOF echo modified sm/untracked git status --ignore-submodules=untracked output @@ -1177,6 +1194,7 @@ Untracked files: expect output untracked + EOF git status --ignore-submodules=untracked output test_i18ncmp expect output @@ -1238,6 +1256,7 @@ Untracked files: expect output untracked + EOF git status --ignore-submodules=untracked output test_i18ncmp expect output @@ -1319,6 +1338,7 @@ cat expect EOF ; expect ; output ; untracked +; EOF test_expect_success status (core.commentchar with submodule summary) ' @@ -1352,6 +1372,7 @@ Untracked files: expect output untracked + no changes added to commit (use git add and/or git commit -a) EOF git status --ignore-submodules=all output diff --git a/wt-status.c b/wt-status.c index 3c795da..2a9ca0f 100644 --- a/wt-status.c +++ b/wt-status.c @@ -751,7 +751,7 @@ static void wt_status_print_other(struct wt_status *s, strbuf_release(buf); if (!column_active(s-colopts)) - return; + goto conclude; strbuf_addf(buf, %s%s\t%s, color(WT_STATUS_HEADER, s), @@ -765,6 +765,8 @@ static void wt_status_print_other(struct wt_status *s, print_columns(output, s-colopts,
[PATCH v5 2/6] wt-status: use argv_array API
No behavior change, but two slight code reorganization: argv_array_push
doesn't accept NULL strings, and duplicates its argument hence
summary_limit must be written to before being inserted into argv.
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
wt-status.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index cb24f1f..958a53c 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -8,6 +8,7 @@
#include diffcore.h
#include quote.h
#include run-command.h
+#include argv-array.h
#include remote.h
#include refs.h
#include submodule.h
@@ -663,29 +664,30 @@ static void wt_status_print_submodule_summary(struct
wt_status *s, int uncommitt
char summary_limit[64];
char index[PATH_MAX];
const char *env[] = { NULL, NULL };
- const char *argv[8];
-
- env[0] =index;
- argv[0] = submodule;
- argv[1] = summary;
- argv[2] = uncommitted ? --files : --cached;
- argv[3] = --for-status;
- argv[4] = --summary-limit;
- argv[5] = summary_limit;
- argv[6] = uncommitted ? NULL : (s-amend ? HEAD^ : HEAD);
- argv[7] = NULL;
+ struct argv_array argv = ARGV_ARRAY_INIT;
sprintf(summary_limit, %d, s-submodule_summary);
snprintf(index, sizeof(index), GIT_INDEX_FILE=%s, s-index_file);
+ env[0] = index;
+ argv_array_push(argv, submodule);
+ argv_array_push(argv, summary);
+ argv_array_push(argv, uncommitted ? --files : --cached);
+ argv_array_push(argv, --for-status);
+ argv_array_push(argv, --summary-limit);
+ argv_array_push(argv, summary_limit);
+ if (!uncommitted)
+ argv_array_push(argv, s-amend ? HEAD^ : HEAD);
+
memset(sm_summary, 0, sizeof(sm_summary));
- sm_summary.argv = argv;
+ sm_summary.argv = argv.argv;
sm_summary.env = env;
sm_summary.git_cmd = 1;
sm_summary.no_stdin = 1;
fflush(s-fp);
sm_summary.out = dup(fileno(s-fp));/* run_command closes it */
run_command(sm_summary);
+ argv_array_clear(argv);
}
static void wt_status_print_other(struct wt_status *s,
--
1.8.4.5.g8688bea
--
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 0/6] Disable git status comment prefix
Compared to v5: * One test update I had forgotten. Now, the testsuite actually pass. * Changed the config to status.displayCommentPrefix. * Added the last patch, to add a missing blank line. Matthieu Moy (6): builtin/stripspace.c: fix broken indentation wt-status: use argv_array API submodule summary: ignore --for-status option status: disable display of '#' comment prefix by default tests: don't set status.displayCommentPrefix file-wide status: add missing blank line after list of other files Documentation/config.txt | 7 + builtin/commit.c | 10 + builtin/stripspace.c | 8 +- git-submodule.sh | 13 +- t/t3001-ls-files-others-exclude.sh | 2 +- t/t7060-wtstatus.sh| 109 +++-- t/t7401-submodule-summary.sh | 12 +- t/t7508-status.sh | 965 - t/t7512-status-help.sh | 600 +++ wt-status.c| 91 +++- wt-status.h| 1 + 11 files changed, 966 insertions(+), 852 deletions(-) -- 1.8.4.5.g8688bea -- 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] upload-pack: send the HEAD information
Andreas Krey a.k...@gmx.de writes:
From: Junio C Hamano gits...@pobox.com
This implements the server side of protocol extension to show which branch
the HEAD points at. The information is sent as a capability symref=target.
Signed-off-by: Junio C Hamano gits...@pobox.com
Signed-off-by: Andreas Krey a.k...@gmx.de
---
upload-pack.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 127e59a..390d1ec 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -745,13 +745,17 @@ static int send_ref(const char *refname, const unsigned
char *sha1, int flag, vo
if (mark_our_ref(refname, sha1, flag, cb_data))
return 0;
- if (capabilities)
- packet_write(1, %s %s%c%s%s%s agent=%s\n,
+ if (capabilities) {
+ unsigned char dummy[20];
+ const char *target = resolve_ref_unsafe(HEAD, dummy, 0, NULL);
+ packet_write(1, %s %s%c%s%s%s%s%s agent=%s\n,
sha1_to_hex(sha1), refname_nons,
0, capabilities,
allow_tip_sha1_in_want ? allow-tip-sha1-in-want
: ,
stateless_rpc ? no-done : ,
+ target ? symref= : , target ? target : 0,
git_user_agent_sanitized());
+ }
else
packet_write(1, %s %s\n, sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
I think it is perfectly fine to expose _only_ HEAD now, and wait
until we find a good reason that we should send this information for
other symbolic refs in the repository.
However, because we already anticipate that we may find such a good
reason later, on-the-wire format should be prepared to support such
later enhancement. I think sending
symref=HEAD:refs/heads/master
is probably one good way to do so, as Peff suggested in that old
thread ($gmane/102070; note that back then this wasn't suggested as
a proper capability so the exact format he suggests in the message
is different). Then we could later add advertisements for other
symbolic refs if we find it necessary to do so, e.g.
symref=HEAD:refs/heads/master
symref=refs/remotes/origin/HEAD:refs/remotes/origin/master
(all on one line together with other capabilities separated with a
SP in between).
--
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 4/6] status: disable display of '#' comment prefix by default
Historically, git status needed to prefix each output line with '#' so
that the output could be added as comment to the commit message. This
prefix comment has no real purpose when git status is ran from the
command-line, and this may distract users from the real content.
Disable this prefix comment by default, and make it re-activable for
users needing backward compatibility with status.displayCommentPrefix.
Obviously, git commit ignores status.displayCommentPrefix and keeps the
comment unconditionnaly when writing to COMMIT_EDITMSG (but not when
writing to stdout for an error message or with --dry-run).
Signed-off-by: Matthieu Moy matthieu@imag.fr
Signed-off-by: Junio C Hamano gits...@pobox.com
---
Documentation/config.txt | 7 +
builtin/commit.c | 10 ++
t/t3001-ls-files-others-exclude.sh | 2 +-
t/t7060-wtstatus.sh| 4 +++
t/t7508-status.sh | 63 +++---
t/t7512-status-help.sh | 4 +++
wt-status.c| 40 +---
wt-status.h| 1 +
8 files changed, 114 insertions(+), 17 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index ec57a15..60c6bc9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2118,6 +2118,13 @@ status.branch::
Set to true to enable --branch by default in linkgit:git-status[1].
The option --no-branch takes precedence over this variable.
+status.displayCommentPrefix::
+ If set to true, linkgit:git-status[1] will insert a comment
+ prefix before each output line (starting with
+ `core.commentChar`, i.e. `#` by default). This was the
+ behavior of linkgit:git-status[1] in Git 1.8.4 and previous.
+ Defaults to false.
+
status.showUntrackedFiles::
By default, linkgit:git-status[1] and linkgit:git-commit[1] show
files which are not currently tracked by Git. Directories which
diff --git a/builtin/commit.c b/builtin/commit.c
index 10acc53..61975ad 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -599,6 +599,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
const char *hook_arg2 = NULL;
int ident_shown = 0;
int clean_message_contents = (cleanup_mode != CLEANUP_NONE);
+ int old_display_comment_prefix;
/* This checks and barfs if author is badly specified */
determine_author_info(author_ident);
@@ -696,6 +697,10 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
if (s-fp == NULL)
die_errno(_(could not open '%s'), git_path(commit_editmsg));
+ /* Ignore status.displayCommentPrefix: we do need comments in
COMMIT_EDITMSG. */
+ old_display_comment_prefix = s-display_comment_prefix;
+ s-display_comment_prefix = 1;
+
if (clean_message_contents)
stripspace(sb, 0);
@@ -821,6 +826,7 @@ static int prepare_to_commit(const char *index_file, const
char *prefix,
*/
if (!commitable whence != FROM_MERGE !allow_empty
!(amend is_a_merge(current_head))) {
+ s-display_comment_prefix = old_display_comment_prefix;
run_status(stdout, index_file, prefix, 0, s);
if (amend)
fputs(_(empty_amend_advice), stderr);
@@ -1182,6 +1188,10 @@ static int git_status_config(const char *k, const char
*v, void *cb)
s-use_color = git_config_colorbool(k, v);
return 0;
}
+ if (!strcmp(k, status.displaycommentprefix)) {
+ s-display_comment_prefix = git_config_bool(k, v);
+ return 0;
+ }
if (!prefixcmp(k, status.color.) || !prefixcmp(k, color.status.)) {
int slot = parse_status_slot(k, 13);
if (slot 0)
diff --git a/t/t3001-ls-files-others-exclude.sh
b/t/t3001-ls-files-others-exclude.sh
index f0421c0..b2798fe 100755
--- a/t/t3001-ls-files-others-exclude.sh
+++ b/t/t3001-ls-files-others-exclude.sh
@@ -115,7 +115,7 @@ EOF
git config core.excludesFile excludes-file
-git status | grep ^#output
+git -c status.displayCommentPrefix=true status | grep ^#output
cat expect EOF
# .gitignore
diff --git a/t/t7060-wtstatus.sh b/t/t7060-wtstatus.sh
index 52ef06b..5ecafac 100755
--- a/t/t7060-wtstatus.sh
+++ b/t/t7060-wtstatus.sh
@@ -4,6 +4,10 @@ test_description='basic work tree status reporting'
. ./test-lib.sh
+test_expect_success 'use status.displayCommentPrefix by default ' '
+ git config --global status.displayCommentPrefix true
+'
+
test_expect_success setup '
git config --global advice.statusuoption false
test_commit A
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index ac3d0fe..8d28280 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -7,6 +7,10 @@ test_description='git status'
.
Re: [PATCH 2/3] connect.c: save symref info from server capabilities
Andreas Krey a.k...@gmx.de writes:
Signed-off-by: Andreas Krey a.k...@gmx.de
---
connect.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/connect.c b/connect.c
index a0783d4..98c4868 100644
--- a/connect.c
+++ b/connect.c
@@ -72,8 +72,8 @@ struct ref **get_remote_heads(int in, char *src_buf, size_t
src_len,
for (;;) {
struct ref *ref;
unsigned char old_sha1[20];
- char *name;
- int len, name_len;
+ char *name, *symref;
+ int len, name_len, symref_len;
char *buffer = packet_buffer;
len = packet_read(in, src_buf, src_len,
@@ -94,9 +94,12 @@ struct ref **get_remote_heads(int in, char *src_buf,
size_t src_len,
name = buffer + 41;
name_len = strlen(name);
+ symref = 0;
if (len != name_len + 41) {
free(server_capabilities);
server_capabilities = xstrdup(name + name_len + 1);
+ symref = parse_feature_value(server_capabilities,
+ symref, symref_len);
}
if (extra_have
@@ -108,6 +111,10 @@ struct ref **get_remote_heads(int in, char *src_buf,
size_t src_len,
if (!check_ref(name, name_len, flags))
continue;
ref = alloc_ref(buffer + 41);
+ if (symref) {
+ ref-symref = xcalloc(symref_len + 1, 1);
+ strncpy(ref-symref, symref, symref_len);
+ }
hashcpy(ref-old_sha1, old_sha1);
*list = ref;
list = ref-next;
This looks utterly wrong. HEAD may happen to be the first ref that
is advertised and hence capability list typically comes on it, but
that does not necessarily have to be the case from the protocol's
correctness point of view.
I think this function should do this instead.
- inside the loop, collect the symref=... capabilities;
- after the loop, look at the symref=... capabilities, and
among the refs the loop added to the *list, find the HEAD
ref and set its -symref to point at an appropirate ref.
--
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: A naive proposal for preventing loose object explosions
On Friday, September 06, 2013 11:19:02 am Junio C Hamano wrote: mf...@codeaurora.org writes: Object lookups should likely not get any slower than if repack were not run, and the extra new pack might actually help find some objects quicker. In general, having an extra pack, only to keep objects that you know are available in other packs, will make _all_ object accesses, not just the ones that are contained in that extra pack, slower. My assumption was that if the new pack, with all the consolidated reachable objects in it, happens to be searched first, it would actually speed things up. And if it is searched last, then the objects weren't in the other packs so how could it have made it slower? It seems this would only slow down the missing object path? But it sounds like all the index files are mmaped up front? Then yes, I can see how it would slow things down. However, it is one only extra (hopefully now well optimized) pack. My base assumption was that even if it does slow things down, it would likely be unmeasurable and a price worth paying to avoid an extreme penalty. Instead of mmapping all the .idx files for all the available packfiles, we could build a table that records, for each packed object, from which packfile at what offset the data is available to optimize the access, but obviously building that in-core table will take time, so it may not be a good trade-off to do so at runtime (a precomputed super-.idx that we can mmap at runtime might be a good way forward if that turns out to be the case). Does this sound like it would work? Sorry, but it is unclear what problem you are trying to solve. I think you guessed it below, I am trying to prevent loose object explosions by keeping unreachable objects around in packs (instead of loose) until expiry. With the current way that pack-objects works, this is the best I could come up with (I said naive). :( Today the git-repack calls git pack-objects like this: git pack-objects --keep-true-parents --honor-pack-keep -- non-empty --all --reflog $args /dev/null $PACKTMP This has no mechanism to place unreachable objects in a pack. If git pack-objects supported an option which streamed them to a separate file (as you suggest below), that would likely be the main piece needed to avoid the heavy-handed approach I was suggesting. The problem is how to define the interface for this? How do we get the filename of the new unreachable packfile? Today the name of the new packfile is sent to stdout, would we just tack on another name? That seems like it would break some assumptions? Maybe it would be OK if it only did that when an --unreachable flag was added? Then git-repack could be enhanced to understand that flag and the extra filenames it outputs? Is it that you do not like that repack -A ejects unreferenced objects and makes it loose, which you may have many? Yes, several times a week we have people pushing the kernel to wrong projects, this leads to 4M loose objects. :( Without a solution for this regular problem, we are very scared to move our repos off of SSDs. This leads to hour plus long fetches. The loosen_unused_packed_objects() function used by repack -A calls the force_object_loose() function (actually, it is the sole caller of the function). If you tweak the latter to stream to a single new graveyard packfile and mark it as kept until expiry, would it solve the issue the same way but with much smaller impact? Yes. There already is an infrastructure available to open a single output packfile and send multiple objects to it in bulk-checkin.c, and I am wondering if you can take advantage of the framework. The existing interface to it assumes that the object data is coming from a file descriptor (the interface was built to support bulk-checkin of many objects in an empty repository), and it needs refactoring to allow stream_to_pack() to take different kind of data sources in the form of stateful callback function, though. That feels beyond what I could currently dedicate the time to do. Like I said, my solution is heavy handed but it felt simple enough for me to try. I can spare the extra disk space and I am not convinced the performance hit would be bad. I would, of course, be delighted if someone else were to do what you suggest, but I get that it's my itch... -Martin -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 0/5] Disable git status comment prefix
Matthieu Moy matthieu@grenoble-inp.fr writes: Untracked files: t/foo test-obj-pool test-string-pool test-treap test-url-normalize nothing added to commit but untracked files present The added blank line before nothing added sounds like a good idea. I won't change the header part in this topic (no time, sorry), but the missing newline before nothing added actually sounds like a bug, as there is normally a newline after each list of file in `git status`, except untracked and ignored. Actually, nothing added ... is not a part of status proper; it will be clear if you run the command with comment prefix, whose output may end like so: # Untracked files: # (use git add file... to include in what will be committed) # # gomi # kuzu nothing added to commit but untracked files present (use git add to track) But I agree that the output without comment prefix needs an extra blank before that line (if that line will be emitted, that is). -- 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 v5 6/6] status: add missing blank line after list of other files
Matthieu Moy matthieu@imag.fr writes: List of files in other sections (Changes to be committed, ...) end with a blank line. It is not like we want to add a blank line at the end of each element; it is rather that we want to have a blank line between each element, so that they can have a bit of breathing room between them. The output looks especially bad when there is nothing after the 'untracked' list. Signed-off-by: Matthieu Moy matthieu@imag.fr --- t/t7508-status.sh | 21 + wt-status.c | 4 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index d0444d3..9bf9701 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -84,6 +84,7 @@ test_expect_success 'status --column' ' # #dir1/untracked dir2/untracked output #dir2/modified expect untracked +# EOF COLUMNS=50 git -c status.displayCommentPrefix=true status --column=column dense output test_i18ncmp expect output @@ -117,6 +118,7 @@ cat expect \EOF #expect #output #untracked +# EOF test_expect_success 'status with status.displayCommentPrefix=true' ' @@ -167,6 +169,7 @@ Untracked files: expect output untracked + EOF test_expect_success 'status (advice.statusHints false)' ' @@ -241,6 +244,7 @@ Untracked files: (use git add file... to include in what will be committed) dir2/modified + Ignored files: (use git add -f file... to include in what will be committed) @@ -250,6 +254,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -308,6 +313,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -430,6 +436,7 @@ Untracked files: expect output untracked + EOF git status -unormal output test_i18ncmp expect output @@ -488,6 +495,7 @@ Untracked files: expect output untracked + EOF git status -uall output test_i18ncmp expect output @@ -548,6 +556,7 @@ Untracked files: ../expect ../output ../untracked + EOF (cd dir1 git status) output test_i18ncmp expect output @@ -618,6 +627,7 @@ Untracked files: BLUEexpectRESET BLUEoutputRESET BLUEuntrackedRESET + EOF test_config color.ui always git status | test_decode_color output @@ -747,6 +757,7 @@ Untracked files: expect output untracked + EOF test_config status.relativePaths false (cd dir1 git status) output @@ -789,6 +800,7 @@ Untracked files: expect output untracked + EOF git commit --dry-run dir1/modified output test_i18ncmp expect output @@ -838,6 +850,7 @@ Untracked files: expect output untracked + EOF git status output test_i18ncmp expect output @@ -902,6 +915,7 @@ Untracked files: expect output untracked + EOF git config status.submodulesummary 10 git status output @@ -952,6 +966,7 @@ Untracked files: expect output untracked + no changes added to commit (use git add and/or git commit -a) EOF git commit -m commit submodule @@ -1012,6 +1027,7 @@ Untracked files: expect output untracked + EOF git config status.submodulesummary 10 git commit --dry-run --amend output @@ -1066,6 +1082,7 @@ Untracked files: expect output untracked + EOF echo modified sm/untracked git status --ignore-submodules=untracked output @@ -1177,6 +1194,7 @@ Untracked files: expect output untracked + EOF git status --ignore-submodules=untracked output test_i18ncmp expect output @@ -1238,6 +1256,7 @@ Untracked files: expect output untracked + EOF git status --ignore-submodules=untracked output test_i18ncmp expect output @@ -1319,6 +1338,7 @@ cat expect EOF ;expect ;output ;untracked +; EOF test_expect_success status (core.commentchar with submodule summary) ' @@ -1352,6 +1372,7 @@ Untracked files: expect output untracked + no changes added to commit (use git add and/or git commit -a) EOF git status --ignore-submodules=all output diff --git a/wt-status.c b/wt-status.c index 3c795da..2a9ca0f 100644 --- a/wt-status.c +++ b/wt-status.c @@ -751,7 +751,7 @@ static void wt_status_print_other(struct wt_status *s, strbuf_release(buf); if (!column_active(s-colopts)) - return; + goto conclude; strbuf_addf(buf, %s%s\t%s, color(WT_STATUS_HEADER, s), @@ -765,6 +765,8 @@ static void
Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.
Philip Oakley philipoak...@iee.org writes: Does this have any impact on the alleged bug in `git bundle --all` (which can then be cloned from) where the current HEAD ref wasn't included in the bundle? Or am I mis-remembering? Not current HEAD ref, but git clone will fail to check out from a bundle that does not include HEAD ref (it is easy to just say reset --hard master or whatever after it, though). I think I suggested to update git bundle to include HEAD when there is no HEAD specified some time ago, but I do not think anybody was interested, so this may be a non-issue. -- 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 v5 6/6] status: add missing blank line after list of other files
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@imag.fr writes: List of files in other sections (Changes to be committed, ...) end with a blank line. It is not like we want to add a blank line at the end of each element; it is rather that we want to have a blank line between each element, so that they can have a bit of breathing room between them. The output looks especially bad when there is nothing after the 'untracked' list. We might want to revisit this later, but I take the above back at least for now. If we have absolutely nothing, we get this: $ git status On branch master nothing to commit $ And if we have something, we get this: $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) new file: foo $ git status On branch master Untracked files: (use git add file... to include in what will be committed) bar nothing added to commit $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) new file: foo Untracked files: (use git add file... to include in what will be committed) bar $ Given that we are already giving an unnecessary trailing blank line in the fully added without no untracked case, it is not too bad to add the same after the list of untracked files. To properly fix this, we would need to refactor wt_status_print_* which will get rid of wt_status_print_trailer(), so that routines that produce each section is told if there is a previous output and adds a separating line _before_ it emits anything on its own (i.e. we switch from the after we spit our stuff out, we leave a blank line mental model to we are going to spit our stuff out but we need a blank before it to separate our stuff from the previous output), and returns if the output now has something to the caller so that the caller can pass that information to the function that outputs the next section. But until that happens, adding a trailing blank line unconditionally is an OK thing to do, I think. Signed-off-by: Matthieu Moy matthieu@imag.fr --- t/t7508-status.sh | 21 + wt-status.c | 4 +++- 2 files changed, 24 insertions(+), 1 deletion(-) diff --git a/t/t7508-status.sh b/t/t7508-status.sh index d0444d3..9bf9701 100755 --- a/t/t7508-status.sh +++ b/t/t7508-status.sh @@ -84,6 +84,7 @@ test_expect_success 'status --column' ' # # dir1/untracked dir2/untracked output # dir2/modified expect untracked +# EOF COLUMNS=50 git -c status.displayCommentPrefix=true status --column=column dense output test_i18ncmp expect output @@ -117,6 +118,7 @@ cat expect \EOF # expect # output # untracked +# EOF test_expect_success 'status with status.displayCommentPrefix=true' ' @@ -167,6 +169,7 @@ Untracked files: expect output untracked + EOF test_expect_success 'status (advice.statusHints false)' ' @@ -241,6 +244,7 @@ Untracked files: (use git add file... to include in what will be committed) dir2/modified + Ignored files: (use git add -f file... to include in what will be committed) @@ -250,6 +254,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -308,6 +313,7 @@ Ignored files: expect output untracked + EOF git status --ignored output test_i18ncmp expect output @@ -430,6 +436,7 @@ Untracked files: expect output untracked + EOF git status -unormal output test_i18ncmp expect output @@ -488,6 +495,7 @@ Untracked files: expect output untracked + EOF git status -uall output test_i18ncmp expect output @@ -548,6 +556,7 @@ Untracked files: ../expect ../output ../untracked + EOF (cd dir1 git status) output test_i18ncmp expect output @@ -618,6 +627,7 @@ Untracked files: BLUEexpectRESET BLUEoutputRESET BLUEuntrackedRESET + EOF test_config color.ui always git status | test_decode_color output @@ -747,6 +757,7 @@ Untracked files: expect output untracked + EOF test_config status.relativePaths false (cd dir1 git status) output @@ -789,6 +800,7 @@ Untracked files: expect output untracked + EOF git commit --dry-run dir1/modified output test_i18ncmp expect output @@ -838,6 +850,7 @@ Untracked files: expect output untracked + EOF git status output test_i18ncmp expect output @@ -902,6 +915,7 @@ Untracked files: expect output untracked + EOF git config status.submodulesummary
Re: [PATCH v4 0/5] Disable git status comment prefix
Junio C Hamano gits...@pobox.com writes: Actually, nothing added ... is not a part of status proper; it will be clear if you run the command with comment prefix, whose output may end like so: # Untracked files: # (use git add file... to include in what will be committed) # # gomi # kuzu nothing added to commit but untracked files present (use git add to track) But I agree that the output without comment prefix needs an extra blank before that line (if that line will be emitted, that is). Even when the line is not emitted, we normally do: # On branch master # Changes to be committed: # (use git reset HEAD file... to unstage) # # modified: foo.txt # (with the last #-only line), so there's no reason to behave differently when the last lines are Untracked files. -- 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: [PATCH v5 6/6] status: add missing blank line after list of other files
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@imag.fr writes:
List of files in other sections (Changes to be committed, ...) end with
a blank line.
It is not like we want to add a blank line at the end of each
element; it is rather that we want to have a blank line between each
element, so that they can have a bit of breathing room between them.
Well, between each element, and at the end of the output sounds a lot
like after each element ;-).
There is a difference between terminator and separator semantics.
LF is a line terminator; it is attached to the end of each line, it
does not come between each pair of adjacent lines. Hence a text file
ends with a LF.
A blank line that separates each C function in our sources is a
separator. That is why a patch that does
@@ -99,3 +99,8 @@ int false(void)
{
return 0;
}
+
+int true(void)
+{
+ return 1;
+}
does not add a trailing blank line at the end.
And I am saying that the blank lines in status output should be
separators, not terminators of sections.
But see the other message.
--
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 v5 6/6] status: add missing blank line after list of other files
Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@imag.fr writes: List of files in other sections (Changes to be committed, ...) end with a blank line. It is not like we want to add a blank line at the end of each element; it is rather that we want to have a blank line between each element, so that they can have a bit of breathing room between them. Well, between each element, and at the end of the output sounds a lot like after each element ;-). -- 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-p4 out of memory for very large repository
On Mon, Sep 02, 2013 at 08:42:36PM +0100, Luke Diamand wrote: I guess you could try changing the OOM score for git-fast-import. change /proc/pid/oomadj. I think a value of -31 would make it very unlikely to be killed. On 29/08/13 23:46, Pete Wyckoff wrote: I usually just do git p4 sync @505859. The error message below crops up when things get confused. Usually after a previous error. I tend to destroy the repo and try again. Sorry I don't can't explain better what's happening here. It's not a memory issue; it reports only 24 MB used. Bizarre. There is no good explanation why memory usage would go up to 32 GB (?) within one top interval (3 sec ?). My theory about one gigantic object is debunked: you have only the 118 MB one. Perhaps there's some container or process memory limit, as Luke guessed, but it's not obvious here. The other big hammer is strace. If you're still interested in playing with this, you could do: strace -vf -tt -s 200 -o /tmp/strace.out git p4 clone and hours later, see if something suggests itself toward the end of that output file. -- Pete Finally, I claim success! Unfortunately I did not try either of the OOM score or strace suggestions - sorry! After spending so much time on this, I've gotten to the point that I'm more interested in getting it to work than in figuring out why the direct approach isn't working; it sounds like you're both pretty confident that git is working as it should, and I don't maintain the system I'm doing this on so I don't doubt that there might be some artificial limit or other quirk here that we just aren't seeing. Anyway, what I found is that Pete's incremental method does work, I just have to know how to do it properly! This is what I WAS doing to generate the error message I pasted several posts ago: git clone //path/to/branch@begin,stage1 cd branch git sync //path/to/branch@stage2 # ERROR! # (I also tried //path/to/branch@stage1+1,stage2, same error) Eventually what happened is that I downloaded the free 20-user p4d, set up a very small repository with only 4 changes, and started some old fashioned trial-and-error. Here's what I should have been doing all along: git clone //path/to/branch@begin,stage1 cd branch git sync //path/to/branch@begin,stage2 git sync //path/to/branch@begin,stage3 # and so on... And syncing a few thousand changes every day over the course of the past week, my git repo is finally up to the Perforce HEAD. So I suppose ultimately this was my own misunderstanding, partly because when you begin your range at the original first change number the output looks suspiciously like it's importing changes again that it's already imported. Maybe this is all documented somewhere, and if it is I just failed to find it. Thanks to both of you for all your help! Corey -- 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: coming from git, understanding mercurial branching
On 2013-09-06 17:51, Konstantin Khomoutov wrote: I found this guide [1] very useful back in the time I tried to grok Mercurial. 1. http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ Indeed, after reading it, that's the most sense I've been able to make of Mercurial's strange branching. I guess it boils down to the following rough heuristic: - if you want to dink around locally, but don't want to publish your branches (yet), default to bookmarks using hg bookmark - once you want a branch to be public, consider making a real branch using hg branch - if you want complete isolation in case you screw up something like merging, use a clone I still prefer Git's way, but at least I'm not left scratching my head when I have to play with Mercurial branches. Thanks, all. -tkc -- 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 2/3] connect.c: save symref info from server capabilities
On Fri, 06 Sep 2013 10:56:51 +, Junio C Hamano wrote:
Andreas Krey a.k...@gmx.de writes:
...
+ if (symref) {
+ ref-symref = xcalloc(symref_len + 1, 1);
+ strncpy(ref-symref, symref, symref_len);
+ }
...
This looks utterly wrong. HEAD may happen to be the first ref that
is advertised and hence capability list typically comes on it, but
that does not necessarily have to be the case from the protocol's
correctness point of view.
Ok, then I misunderstood that part. I thought we'd be going to
put the symref (if any) into 'capabilities' on the respective ref,
but putting them all in one capability list sounds saner all in all.
I think this function should do this instead.
- inside the loop, collect the symref=... capabilities;
- after the loop, look at the symref=... capabilities, and
among the refs the loop added to the *list, find the HEAD
ref and set its -symref to point at an appropirate ref.
Fair game. There goes the parse_feature_value; will have to iterate
another way (or look them (symref=#{name}:) up instead of collecting
them into a hash beforehand).
Can I assume that the only capability list is always on the
first ref sent (as it is now)?
(And besides, is there something more suitable for the
xcalloc/strncpy combination?)
Andreas
--
Totally trivial. Famous last words.
From: Linus Torvalds torvalds@*.org
Date: Fri, 22 Jan 2010 07:29:21 -0800
--
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 2/3] connect.c: save symref info from server capabilities
Andreas Krey a.k...@gmx.de writes: Can I assume that the only capability list is always on the first ref sent (as it is now)? The capability list _could_ be sent more than once, and the receiving end is prepared to accept such a stream. Everything learned from an older capability list needs to be forgot and only the last one is honored, I think. -- 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-VERSION-GEN: Do not require tags to be annotated
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b444c18..68b61e3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -12,7 +12,7 @@ if test -f version
then
VN=$(cat version) || VN=$DEF_VER
elif test -d ${GIT_DIR:-.git} -o -f .git
- VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null)
+ VN=$(git describe --tags --match v[0-9]* --abbrev=7 HEAD 2/dev/null)
case $VN in
*$LF*) (exit 1) ;;
v[0-9]*)
--
1.8.3.msysgit.1.3.g5b82b42.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: [PATCH 1/3] upload-pack: send the HEAD information
Andreas Krey a.k...@gmx.de writes: On Fri, 06 Sep 2013 10:46:24 +, Junio C Hamano wrote: Andreas Krey a.k...@gmx.de writes: ... reason later, on-the-wire format should be prepared to support such later enhancement. I think sending symref=HEAD:refs/heads/master Mirco-bikeshed: Should that possibly be symref:HEAD=refs/heads/master as then 'symref:HEAD' is a regular capability key? I doubt that is a good change. We haven't needed (and have refrained from adding) any capability with an unknown name. The variable part should go to the value portion of the token. -- 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 v5 1/7] replace: forbid replacing an object with one of a different type
Christian Couder chrisc...@tuxfamily.org writes: + obj_type = sha1_object_info(object, NULL); + repl_type = sha1_object_info(repl, NULL); That we can do this is somewhat curious. If an object is replaced with a different one, would it mean that this code snippet is totally bogus? type1 = sha1_object_info(sha1, size1); area = xmalloc(size1); orig = read_sha1_file(sha1, type0, size0); memcpy(area, orig, size1); free(orig); + if (!force obj_type != repl_type) + die(Objects must be of the same type.\n + '%s' points to a replaced object of type '%s'\n + while '%s' points to a replacement object of type '%s'., + object_ref, typename(obj_type), + replace_ref, typename(repl_type)); + if (read_ref(ref, prev)) hashclr(prev); else if (!force) -- 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/5] t2024: Fix inconsequential typos
On Fri, Sep 6, 2013 at 7:32 PM, Junio C Hamano gits...@pobox.com wrote: Johan Herland jo...@herland.net writes: diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh index dee55e4..6c78fba 100755 --- a/t/t2024-checkout-dwim.sh +++ b/t/t2024-checkout-dwim.sh @@ -113,9 +113,9 @@ test_expect_success 'setup more remotes with unconventional refspecs' ' cd repo_d test_commit d_master git checkout -b baz - test_commit f_baz + test_commit d_baz Not limited to this hunk but there seems to be a breakage in the chain here. Thanks, found 2 instances in the file (both in that test). Will be fixed in the next iteration. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- 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 10/38] pack v4: commit object encoding
On Thu, 5 Sep 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: This goes as follows: - Tree reference: either variable length encoding of the index into the SHA1 table or the literal SHA1 prefixed by 0 (see encode_sha1ref()). - Parent count: variable length encoding of the number of parents. This is normally going to occupy a single byte but doesn't have to. - List of parent references: a list of encode_sha1ref() encoded references, or nothing if the parent count was zero. - Author reference: variable length encoding of an index into the author identifier dictionary table which also covers the time zone. To make the overall encoding efficient, the author table is sorted by usage frequency so the most used names are first and require the shortest index encoding. - Author time stamp: variable length encoded. Year 2038 ready! - Committer reference: same as author reference. - Committer time stamp: same as author time stamp. The remainder of the canonical commit object content is then zlib compressed and appended to the above. Rationale: The most important commit object data is densely encoded while requiring no zlib inflate processing on access, and all SHA1 references are most likely to be direct indices into the pack index file requiring no SHA1 search into the pack index file. May I suggest a small change to the above, though. Reorder the entries so that Parent count, list of parents and committer time stamp come first in this order, and then the rest. That way, commit.c::parse_commit() could populate its field lazily with parsing only the very minimum set of fields, and then the revision walker, revision.c::add_parents_to_list(), can find where in the priority queue to add the parents to the list of commits to be processed while still keeping the object partially parsed. If a commit is UNINTERESTING, no further parsing needs to be done. OK. If I understand correctly, the committer time stamp is more important than the author's, right? Because my latest change in the format was to make the former as a difference against the later and that would obviously have to be reversed. Also, to keep some kind of estetic symetry (if such thing may exist in a raw byte format) may I suggest keeping the tree reference first. That is easy to skip over if you don't need it, something like: if (!*ptr) ptr += 1 + 20; else while (*ptr++ 128); Whereas, for a checkout where only the tree info is needed, if it is located after the list of parents, then the above needs to be done for all those parents and the committer time. Nicolas -- 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 v5 1/7] replace: forbid replacing an object with one of a different type
Junio C Hamano gits...@pobox.com writes: Christian Couder chrisc...@tuxfamily.org writes: +obj_type = sha1_object_info(object, NULL); +repl_type = sha1_object_info(repl, NULL); That we can do this is somewhat curious Note that this was a comment on the sha1_object_info() API, which, unlike read_sha1_file() API, does not seem to interact with the replace mechanism. I _think_ that needs to be rethought by checking each call site, but for the purpose of this series, I think this is the best we can do in this patch. Will queue the whole series. 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 0/3] Reject non-ff pulls by default
John Keeping wrote:
On Thu, Sep 05, 2013 at 12:18:45PM -0700, Junio C Hamano wrote:
I somehow thought that rebase by default looked in the reflog to do
exactly that. Perhaps I am not remembering correctly.
It just does @{upstream} by default, which tends to get messy if the
upstream has been rewritten.
Maybe Junio is thinking of 'git pull --rebase', which walks the reflog
until it finds an ancestor of the current branch and uses that as the
upstream parameter to rebase.
--
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-gui: Modify push dialog to support Gerrit review
On Fri, Sep 6, 2013 at 6:30 AM, Joergen Edelbo j...@napatech.com wrote: Problem: It is not possible to push for Gerrit review as you will always try to push to refs/heads/... on the remote. Changes done: Add an option to select Gerrit review and a corresponding entry for a branch name. If this option is selected, push the changes to refs/for/gerrit-branch/local branch. In this way the local branch names will be used as topic branches on Gerrit. In my gerrit repos, I have this configuration $ git config remote.origin.push HEAD:refs/for/master And so I can simply 'git push' and git does what I mean. My main complaint with git-gui's push is that it ignores my configuration. Can you teach git-gui to honor this setting, instead? I would like for this remote.name.push option to be smarter and figure out which $branch I mean when I am not on master, but that is a different discussion. Having said that, I see that your change to git-gui attempts to make that automatic. Kudos for that, but I don't think this will work for me as I am often on a detached branch and so refs/heads/$b is meaningless. Can you think of a sane way to separate the from and the to branches in the GUI? I mean, I would like to push HEAD and I would like it to go to refs/for/frotz-2.0. Phil -- 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-VERSION-GEN: Do not require tags to be annotated
Sebastian Schuberth sschube...@gmail.com writes:
For custom builds of Git it sometimes is inconvenient to annotate tags
because there simply is nothing to say, so do not require an annotation.
Signed-off-by: Sebastian Schuberth sschube...@gmail.com
---
H, personally I'd actually want this to stay the way it is, or
even require a valid signed tag, in order to make sure I won't
mistakenly creating a lightweight tag.
If you want to give build a custom name,
echo buildname version
should be sufficient, no?
I dunno.
GIT-VERSION-GEN | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
index b444c18..68b61e3 100755
--- a/GIT-VERSION-GEN
+++ b/GIT-VERSION-GEN
@@ -12,7 +12,7 @@ if test -f version
then
VN=$(cat version) || VN=$DEF_VER
elif test -d ${GIT_DIR:-.git} -o -f .git
- VN=$(git describe --match v[0-9]* --abbrev=7 HEAD 2/dev/null)
+ VN=$(git describe --tags --match v[0-9]* --abbrev=7 HEAD 2/dev/null)
case $VN in
*$LF*) (exit 1) ;;
v[0-9]*)
--
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 v5 6/6] status: add missing blank line after list of other files
On Fri, Sep 06, 2013 at 11:42:02AM -0700, Junio C Hamano wrote: It is not like we want to add a blank line at the end of each element; it is rather that we want to have a blank line between each element, so that they can have a bit of breathing room between them. The output looks especially bad when there is nothing after the 'untracked' list. We might want to revisit this later, but I take the above back at least for now. I agree with most of what you say here, and I started to look at a simple patch to give separator semantics. But there's an interesting case. Given this: If we have absolutely nothing, we get this: $ git status On branch master nothing to commit $ I think the lack of extra line delimiter looks fine. But here: And if we have something, we get this: $ git status On branch master Changes to be committed: (use git reset HEAD file... to unstage) new file: foo I think it looks kind of bad, because the branch specifier is is smooshed into the to be committed header. So the logic is not just separate with a newline. It's more like separate big chunks with a newline, but if we only have small chunks, it's OK to stick them together. -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
Re: [PATCH 10/38] pack v4: commit object encoding
Nicolas Pitre n...@fluxnic.net writes: OK. If I understand correctly, the committer time stamp is more important than the author's, right? Yeah, it matters a lot more when doing timestamp based traversal without the reachability bitmaps. ... may I suggest keeping the tree reference first. That is easy to skip over if you don't need it,... ... Whereas, for a checkout where only the tree info is needed, if it is located after the list of parents, then the above needs to be done for all those parents and the committer time. Hmm. I wonder if that is a really good trade-off. checkout is to parse a single commit object and grab the tree field, while log is to parse millions of commit objects to grab their parents and committer timestamp fields (log path/spec needs to grab tree, too, so that does not make tree extremely uncommon compared to the other two fields, though). 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/RFC] t9500-*.sh: Fix highlight test hang on Linux Mint
Linux Mint has an implementation of the highlight command (unrelated
to the one from http://www.andre-simon.de) that works as a simple
filter. The script uses 'sed' to add terminal colour escape codes
around text matching a regular expression. When t9500-*.sh attempts
to run highlight --version, the script simply hangs waiting for
input. (See https://bugs.launchpad.net/linuxmint/+bug/815005).
The tool required by gitweb can be installed from the 'highlight'
package. Unfortunately, given the default $PATH, this leads to the
tool having lower precedence than the script.
In order to allow the user to specify the correct tool, introduce
the GIT_TEST_HIGHLIGHT_BIN variable. Also, add '/dev/null' to the
command line of the highlight invocation; this avoids hanging the
test if the filter script is used nonetheless.
Signed-off-by: Ramsay Jones ram...@ramsay1.demon.co.uk
---
Hi Junio,
I recently upgraded my Ubuntu installation to Linux Mint 15 Cinnamon.
(Unity makes me want to throw my laptop at the wall!)
Having tickled this bug, I solved the problem by building highlight
v3.15 from source and installing in $HOME.
This patch is marked RFC because this bug does not seem to have
affected too many people (given that Heiko reported the problem
back in 2011) ... :-D
[Also, note that I didn't fix up the form of the conditional.]
ATB,
Ramsay Jones
t/t9500-gitweb-standalone-no-errors.sh | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/t/t9500-gitweb-standalone-no-errors.sh
b/t/t9500-gitweb-standalone-no-errors.sh
index 6fca193..0208c8e 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -683,14 +683,18 @@ test_expect_success \
# syntax highlighting
-highlight --version /dev/null 21
+GIT_TEST_HIGHLIGHT_BIN=${GIT_TEST_HIGHLIGHT_BIN:-highlight}
+highlight_version=$($GIT_TEST_HIGHLIGHT_BIN --version /dev/null 2/dev/null)
if [ $? -eq 127 ]; then
- say Skipping syntax highlighting test, because 'highlight' was not
found
+ say Skipping syntax highlighting tests: 'highlight' not found
+elif test -z $highlight_version; then
+ say Skipping syntax highlighting tests: incorrect 'highlight' found
+ say set GIT_TEST_HIGHLIGHT_BIN to full path of highlight program
else
test_set_prereq HIGHLIGHT
- cat gitweb_config.perl -\EOF
- our $highlight_bin = highlight;
- $feature{'highlight'}{'override'} = 1;
+ cat gitweb_config.perl -EOF
+ our \$highlight_bin = $GIT_TEST_HIGHLIGHT_BIN;
+ \$feature{'highlight'}{'override'} = 1;
EOF
fi
--
1.8.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: [PATCH v4 0/5] Disable git status comment prefix
On Fri, Sep 06, 2013 at 07:28:43PM +0200, Matthieu Moy wrote: FWIW, I had the same thought as Junio. I much prefer something like status.displayCommentPrefix for clarity and future-proofing. Sounds fine, but I don't understand why we'd want this to be an option with a future in the first place. Why not just fix the remaining bugs before merging to master and make it unconditional? I think some old-time users may appreciate to have a backward-compatibility option. It doesn't cost much for us, as we need the variable internally (to use the prefix in COMMIT_EDITMSG, and not on stdout), and it actually makes it easier to test. Exactly. I kind of prefer the old output, though it is probably just having my brain rotted from seeing it so much. I'm going to give the new behavior a try for a while to see if I adjust, but ultimately I'd like to have the escape hatch. And as you say, it doesn't cost much, since we have to keep both code paths anyway. I won't change the header part in this topic (no time, sorry), but the missing newline before nothing added actually sounds like a bug, as there is normally a newline after each list of file in `git status`, except untracked and ignored. I'll fix it as a separate patch in the next round. Thanks for looking into it. -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
Re: [PATCH] GIT-VERSION-GEN: Do not require tags to be annotated
On Sep 6, 2013, at 13:10, Sebastian Schuberth wrote: For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation. It's not that hard to add -m to the command line: git tag -a -m new-annotated-tag if you're just trying to avoid the editor or thinking up a message. Is `-m ` really that inconvenient? -- 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/3] Unconfuse git clone when two branches at are HEAD.
From: Junio C Hamano gits...@pobox.com Philip Oakley philipoak...@iee.org writes: Does this have any impact on the alleged bug in `git bundle --all` (which can then be cloned from) where the current HEAD ref wasn't included in the bundle? Or am I mis-remembering? Not current HEAD ref, but git clone will fail to check out from a bundle that does not include HEAD ref (it is easy to just say reset --hard master or whatever after it, though). I think I suggested to update git bundle to include HEAD when there is no HEAD specified some time ago, but I do not think anybody was interested, so this may be a non-issue. Just had a quick look at a very quick test repo (10 objects, 2 branches) and the bundle file does contain the HEAD ref, but again it has the two ref/heads/* are better than one problem, in that the clone from the bundle checks out master, whilst the source repo has feature checked out. Philip -- 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-VERSION-GEN: Do not require tags to be annotated
Junio C Hamano wrote: Sebastian Schuberth sschube...@gmail.com writes: For custom builds of Git it sometimes is inconvenient to annotate tags because there simply is nothing to say, so do not require an annotation. Signed-off-by: Sebastian Schuberth sschube...@gmail.com --- H, personally I'd actually want this to stay the way it is, or even require a valid signed tag, in order to make sure I won't mistakenly creating a lightweight tag. So the only user Git should care about is you? If Git can make _you_ more confortable not making certain mistakes, then that's the way it should be? What's the point of lightweight tags anyway? 'git describe' doesn't use them, GIT-VERSION-GEN neither, just remove them already. For the vast majority of the people out there, a tag is a tag. Period. -- Felipe Contreras -- 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
It is Utterly Privy
It is Private I am George Daniels, a Banker and credit system programmer (HSBC bank). I saw your email address while browsing through the bank D.T.C Screen in my office yesterday so I decided to use this very chance to know you. I believe we should use every opportunity to know each other better. However, I am contacting you for obvious reason which you will understand. I am sending this mail just to know if this email address is OK, reply me back so that I will send more details to you. I have a very important thing to discuss with you, I look forward to receiving your response at georgedani...@postino.net. Have a pleasant day. George Daniels -- 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 10/38] pack v4: commit object encoding
On Fri, 6 Sep 2013, Junio C Hamano wrote: Nicolas Pitre n...@fluxnic.net writes: OK. If I understand correctly, the committer time stamp is more important than the author's, right? Yeah, it matters a lot more when doing timestamp based traversal without the reachability bitmaps. ... may I suggest keeping the tree reference first. That is easy to skip over if you don't need it,... ... Whereas, for a checkout where only the tree info is needed, if it is located after the list of parents, then the above needs to be done for all those parents and the committer time. Hmm. I wonder if that is a really good trade-off. checkout is to parse a single commit object and grab the tree field, while log is to parse millions of commit objects to grab their parents and committer timestamp fields (log path/spec needs to grab tree, too, so that does not make tree extremely uncommon compared to the other two fields, though). I dunno. I've therefore settled in the middle. The patch description now looks like: |This goes as follows: | |- Tree reference: either variable length encoding of the index | into the SHA1 table or the literal SHA1 prefixed by 0 (see | encode_sha1ref()). | |- Parent count: variable length encoding of the number of parents. | This is normally going to occupy a single byte but doesn't have to. | |- List of parent references: a list of encode_sha1ref() encoded | references, or nothing if the parent count was zero. | |- Committer time stamp: variable length encoded. Year 2038 ready! | Unlike the canonical representation, this is stored close to the | list of parents so the important data for history traversal can be | retrieved without parsing the rest of the object. | |- Committer reference: variable length encoding of an index into the | ident dictionary table which also covers the time zone. To make | the overall encoding efficient, the ident table is sorted by usage | frequency so the most used entries are first and require the shortest | index encoding. | |- Author time stamp: encoded as a difference against the committer | time stamp, with the LSB used to indicate commit time is behind | author time. | |- Author reference: same as committer reference. | |The remainder of the canonical commit object content is then zlib |compressed and appended to the above. I also updated the documentation patch accordingly in my tree. Nicolas -- 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 v3] Document pack v4 format
On Fri, 6 Sep 2013, Nguyễn Thái Ngọc Duy wrote:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Should be up to date with Nico's latest implementation and also cover
additions to the format that everybody seems to agree on:
- new types for canonical trees and commits
- sha-1 table covering missing objects in thin packs
Yes, I've tweaked the format again. I've implemented the code needed to
carry canonical commit and tree objects in pack v4. And things are much
simpler if the canonical commit and tree types are identical to pack v2.
Therefore the new types are used for the pack v4 optimized commit and
tree representations.
I've therefore added this patch to my tree (with the needed changes to
the documentation patch):
commit 98d4b75aff266015b5dff0a324a2984c2a8f7fa2
Author: Nicolas Pitre n...@fluxnic.net
Date: Fri Sep 6 23:45:49 2013 -0400
pack v4: allow canonical commit and tree objects
If for some reason we can't transcode a commit or tree object (lossy
encoding such as the zero-padded file mode for example) then we can still
store the canonical object like in pack v2.
This is also useful for completing a thin pack without having to add
missing entries to the dictionary tables.
To simplify things, the canonical commit and tree types retain their type
number 1 and 2 respectively, and the transcoded types are now 9 and 10
i.e. with bit 3 added.
Signed-off-by: Nicolas Pitre n...@fluxnic.net
diff --git a/cache.h b/cache.h
index a6d016b..b68ad5a 100644
--- a/cache.h
+++ b/cache.h
@@ -330,6 +330,8 @@ enum object_type {
/* 5 for future expansion */
OBJ_OFS_DELTA = 6,
OBJ_REF_DELTA = 7,
+ OBJ_PV4_COMMIT = (8 + 1),
+ OBJ_PV4_TREE = (8 + 2),
OBJ_ANY,
OBJ_MAX
};
diff --git a/packv4-create.c b/packv4-create.c
index 11cfe6f..38fa594 100644
--- a/packv4-create.c
+++ b/packv4-create.c
@@ -981,10 +981,15 @@ static off_t packv4_write_object(struct sha1file *f,
struct packed_git *p,
die(unexpected object type %d, type);
}
free(src);
- if (!result)
- die(can't convert %s object %s,
- typename(type), sha1_to_hex(obj-sha1));
+ if (!result) {
+ warning(can't convert %s object %s,
+ typename(type), sha1_to_hex(obj-sha1));
+ /* fall back to copy the object in its original form */
+ return copy_object_data(f, p, obj-offset);
+ }
+ /* Use bit 3 to indicate a special type encoding */
+ type += 8;
hdrlen = write_object_header(f, type, obj_size);
sha1write(f, result, buf_size);
free(result);
diff --git a/packv4-parse.c b/packv4-parse.c
index 86ec535..63bba03 100644
--- a/packv4-parse.c
+++ b/packv4-parse.c
@@ -266,7 +266,7 @@ static int decode_entries(struct packed_git *p, struct
pack_window **w_curs,
if (++scp - src = avail - 20)
return -1;
/* let's still make sure this is actually a tree */
- if ((*scp++ 0xf) != OBJ_TREE)
+ if ((*scp++ 0xf) != OBJ_PV4_TREE)
return -1;
}
diff --git a/sha1_file.c b/sha1_file.c
index 79e1293..c7bf677 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1806,6 +1806,11 @@ static enum object_type packed_to_object_type(struct
packed_git *p,
}
switch (type) {
+ case OBJ_PV4_COMMIT:
+ case OBJ_PV4_TREE:
+ /* hide pack v4 special object types */
+ type -= 8;
+ break;
case OBJ_BAD:
case OBJ_COMMIT:
case OBJ_TREE:
@@ -2171,17 +2176,16 @@ void *unpack_entry(struct packed_git *p, off_t
obj_offset,
if (data)
die(BUG in unpack_entry: left loop at a valid delta);
break;
+ case OBJ_PV4_COMMIT:
+ data = pv4_get_commit(p, w_curs, curpos, size);
+ type -= 8;
+ break;
+ case OBJ_PV4_TREE:
+ data = pv4_get_tree(p, w_curs, curpos, size);
+ type -= 8;
+ break;
case OBJ_COMMIT:
case OBJ_TREE:
- if (p-version = 4 !base_from_cache) {
- if (type == OBJ_COMMIT) {
- data = pv4_get_commit(p, w_curs, curpos, size);
- } else {
- data = pv4_get_tree(p, w_curs, curpos, size);
- }
- break;
- }
- /* fall through */
case OBJ_BLOB:
case OBJ_TAG:
if (!base_from_cache)
Re: [PATCH v3] Document pack v4 format
On Fri, 6 Sep 2013, Nicolas Pitre wrote: On Fri, 6 Sep 2013, Duy Nguyen wrote: In your code you reject sha1ref starting with zero too (sha1_file.c::get_base_delta and packv4-parse.c::decode_entries) Yeah... because I wrote the minimum code to make it work with the current encoder. But the decoder could be more lenient than that. It's just a matter of adding a call to find_pack_entry_one() when the sha1ref index is 0. FYI I've added the missing code to packv4-parse.c::decode_entries. The code in sha1_file.c::get_delta_base was already fine. Nicolas -- 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
Call For Papers
Dear Colleagues, You are invited to upload your papers to our upcoming conferences Paris, France, October 29-31, 2013. More details: http://www.wseas.org Scientific Sponsors: a) University of Zagreb, Croatia, b) Music Academy Studio Musica, Italy, c) Constanta Maritime University, Romania, d) European Institute of Informatics and Educational Technology in Belgrade, Serbia, e) Ain Shams University, Egypt Nanjing, China, November 17-19, 2013. More details: http://www.wseas.org Scientific Sponsors: a) Nanjing Forestry University, China, b) College of Computer Science Department of Biomedical Informatics, Asia University, Taiwan c) Music Academy Studio Musica, Italy, Publication: Accepted Papers will be published in our: (a) Hard-Copy of the Proceedings (Indexed in ISI, SCOPUS, AMS, ACS, CiteSeerX, Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS etc) and (b) CD-ROM Proceedings (Indexed in ISI, SCOPUS, AMS, ACS, CiteSeerX, Zentralblatt, British Library, EBSCO, SWETS, EMBASE, CAS etc) (c) After new peer, thorough review of their extended versions in a well-known Journal (SCOPUS, AMS, Elsevier, Zentrablat, ACM etc... indexed) (d) E-Library with free access REVIEWE PROCESS: Papers in WSEAS Conferences and Journals are subject to thorough peer review. The names of the Reviewers, see: http://www.wseas.org/wseas/cms.action?id=5628 appear in the Proceedings and are, consequently, sent to all collaborating indexes. Qualified colleagues are always invited to participate in the review process. Visit this page for more details: http://www.wseas.org/wseas/cms.action?id=88 Nobody can qualify to become a WSEAS Reviewer without proper academic qualifications (i.e. recent publications in SCOPUS and ISI). Reviewers whose review work is not thorough or who are not longer active are immediately removed from our reviewers' list: http://www.wseas.org/wseas/cms.action?id=5321 Therefore, our list only includes active reviewers. The names of all conference reviewers are also published in the WSEAS post-conference reports. See: http://www.wseas.org/wseas/cms.action?id=87 Additionally, WSEAS is the only academic publisher with open access journals (public PDF on the web plus hard copy), where the authors do not pay any article processing fees. See: http://www.wseas.org/wseas/cms.action?id=43 INVITED PLENARY SPEECHES: See them by conference in http://www.wseas.org Feel free to visit the web site of the conference at http://www.wseas.org for all the information that you need. Each page has a submission link for you to upload your papers. Kindly note that we do not accept papers by email and that you should only upload your full paper as we do not accept abstracts. We are at your disposal if you have any questions. The WSEAS Team Ag. I. Theologou 17-23 Zografou, 15773, Athens, Greece Phone +30 210 747 3313 FAX +30 211 800 1964 URL: http://www.wseas.org This message satisfies the requirements of the European legislation on advertising (Directiva 2002/58/CE of the European Parliament). If you do not wish to receive e-mails from us (i.e.if you want to un~subscribe), send an email to wseas-t...@wseas.org with the following command as Subject: un~subscribe email1, email2, email3, where Email: email1, email2, email3 are all the possible emails that you have. For example un~subscribe johnsm...@gmail.com, jsm...@server.mbu.uk etc.. Please accept our apologies for any inconvenience caused. -- 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
