* What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Junio C Hamano @ 2009-08-24 1:01 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
After the 1.6.5 cycle, the next release will be 1.7.0, and we will push
out the planned "push safety" change. 1.7.0 would be a good time to
introduce "justifiable" changes that are not strictly backward compatible.
During 1.6.5 cycle, 'next' will hold topics meant for 1.6.5 and 1.7.0.
--------------------------------------------------
[Graduated to "master"]
* bc/mailsplit-cr-at-eol (2009-08-04) 4 commits
(merged to 'next' on 2009-08-06 at 6bc7c5c)
+ Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
+ builtin-mailsplit.c: remove read_line_with_nul() since it is no longer used
+ builtin-mailinfo,builtin-mailsplit: use strbufs
+ strbuf: add new function strbuf_getwholeline()
* gb/apply-ignore-whitespace (2009-08-04) 1 commit
(merged to 'next' on 2009-08-06 at 59e2c86)
+ git apply: option to ignore whitespace differences
* cc/replace (2009-05-27) 14 commits.
(merged to 'next' on 2009-08-02 at b9c4bc0)
+ t6050: check pushing something based on a replaced commit
+ Documentation: add documentation for "git replace"
+ Add git-replace to .gitignore
+ builtin-replace: use "usage_msg_opt" to give better error messages
+ parse-options: add new function "usage_msg_opt"
+ builtin-replace: teach "git replace" to actually replace
+ Add new "git replace" command
+ environment: add global variable to disable replacement
+ mktag: call "check_sha1_signature" with the replacement sha1
+ replace_object: add a test case
+ object: call "check_sha1_signature" with the replacement sha1
+ sha1_file: add a "read_sha1_file_repl" function
+ replace_object: add mechanism to replace objects found in "refs/replace/"
+ refs: add a "for_each_replace_ref" function
* ld/p4 (2009-07-30) 1 commit
(merged to 'next' on 2009-08-14 at 36d310d)
+ git-p4: stream from perforce to speed up clones
* mr/gitweb-xz (2009-08-06) 3 commits
(merged to 'next' on 2009-08-14 at b63b8e6)
+ gitweb: add support for XZ compressed snapshots
+ gitweb: update INSTALL regarding specific snapshot settings
+ gitweb: support to globally disable a snapshot format
* jc/verify-pack-stat (2009-08-07) 1 commit
(merged to 'next' on 2009-08-10 at f80d0e9)
+ verify-pack --stat-only: show histogram without verifying
--------------------------------------------------
[New Topics]
* jc/mailinfo-scissors (2009-08-23) 1 commit
- Teach mailinfo to ignore everything before -- >8 -- mark
* tf/diff-whitespace-incomplete-line (2009-08-23) 2 commits.
- xutils: Fix xdl_recmatch() on incomplete lines
- xutils: Fix hashing an incomplete line with whitespaces at the end
* jc/1.7.0-send-email-no-thread-default (2009-08-22) 1 commit
(merged to 'next' on 2009-08-22 at 5106de8)
+ send-email: make --no-chain-reply-to the default
* lt/approxidate (2009-08-22) 2 commits
- Further 'approxidate' improvements
- Improve on 'approxidate'
* mm/reset-report (2009-08-21) 2 commits
- reset: make the reminder output consistent with "checkout"
- Rename REFRESH_SAY_CHANGED to REFRESH_IN_PORCELAIN.
* wl/insta-mongoose (2009-08-21) 1 commit
- Add support for the Mongoose web server.
--------------------------------------------------
[Stalled]
* sr/gfi-options (2009-08-13) 3 commits
- fast-import: test the new option command
- fast-import: add option command
- fast-import: put option parsing code in seperate functions
What is this used by?
* lt/block-sha1 (2009-08-17) 4 commits
(merged to 'next' on 2009-08-18 at 67a1ce8)
+ remove ARM and Mozilla SHA1 implementations
+ block-sha1: guard gcc extensions with __GNUC__
+ make sure byte swapping is optimal for git
+ block-sha1: make the size member first in the context struct
Finishing touches ;-) There were a few Solaris portability patches
floated around that I didn't pick up, waiting for them to finalize.
* js/stash-dwim (2009-07-27) 1 commit.
(merged to 'next' on 2009-08-16 at 67896c4)
+ Make 'git stash -k' a short form for 'git stash save --keep-index'
(this branch is used by tr/reset-checkout-patch.)
* tr/reset-checkout-patch (2009-08-18) 8 commits.
(merged to 'next' on 2009-08-18 at e465bb3)
+ tests: disable interactive hunk selection tests if perl is not available
(merged to 'next' on 2009-08-16 at 67896c4)
+ DWIM 'git stash save -p' for 'git stash -p'
+ Implement 'git stash save --patch'
+ Implement 'git checkout --patch'
+ Implement 'git reset --patch'
+ builtin-add: refactor the meat of interactive_add()
+ Add a small patch-mode testing library
+ git-apply--interactive: Refactor patch mode code
(this branch uses js/stash-dwim.)
There was a discussion on better DWIMmery for the above two topics to (1)
forbid "git stash save --anything-with-dash" and (2) redirect with any
option "git stash --opt" to "git stash save --opt", to keep it flexible
and safe at the same time. I think it is a sane thing to do, but nothing
has happened lately.
* jn/gitweb-blame (2009-08-06) 3 commits
- gitweb: Create links leading to 'blame_incremental' using JavaScript
- gitweb: Incremental blame (WIP)
- gitweb: Add optional "time to generate page" info in footer
Ajax-y blame WIP
* db/vcs-helper (2009-08-09) 17 commits
- Allow helpers to request marks for fast-import
- Allow helpers to report in "list" command that the ref is unchanged
- Add support for "import" helper command
- transport-helper_init(): fix a memory leak in error path
- Add a config option for remotes to specify a foreign vcs
- Allow programs to not depend on remotes having urls
- Allow fetch to modify refs
- Use a function to determine whether a remote is valid
- Use a clearer style to issue commands to remote helpers
(merged to 'next' on 2009-08-07 at f3533ba)
+ Makefile: install hardlinks for git-remote-<scheme> supported by libcurl if possible
+ Makefile: do not link three copies of git-remote-* programs
+ Makefile: git-http-fetch does not need expat
(merged to 'next' on 2009-08-06 at 15da79d)
+ http-fetch: Fix Makefile dependancies
+ Add transport native helper executables to .gitignore
(merged to 'next' on 2009-08-05 at 33d491e)
+ git-http-fetch: not a builtin
+ Use an external program to implement fetching with curl
+ Add support for external programs for handling native fetches
(this branch is used by jh/cvs-helper.)
There was a discussion that suggests that the use of colon ':' before vcs
helper name needs to be corrected. Nothing happened since.
* je/send-email-no-subject (2009-08-05) 1 commit
- send-email: confirm on empty mail subjects
This seems to break t9001. Near the tip of 'pu' I have a iffy
workaround.
--------------------------------------------------
[Cooking]
* cc/sequencer-rebase-i (2009-08-21) 17 commits.
- rebase -i: use "git sequencer--helper --cherry-pick"
- sequencer: add "--cherry-pick" option to "git sequencer--helper"
- sequencer: add "do_commit()" and related functions
- pick: libify "pick_help_msg()"
- revert: libify pick
- rebase -i: use "git sequencer--helper --fast-forward"
- sequencer: let "git sequencer--helper" callers set "allow_dirty"
- sequencer: add "--fast-forward" option to "git sequencer--helper"
- sequencer: add "do_fast_forward()" to perform a fast forward
- rebase -i: use "git sequencer--helper --reset-hard"
- sequencer: add "--reset-hard" option to "git sequencer--helper"
- sequencer: add comments about reset_almost_hard()
- sequencer: add "reset_almost_hard()" and related functions
- rebase -i: use "git sequencer--helper --make-patch"
- sequencer: free memory used in "make_patch" function
- sequencer: add "make_patch" function to save a patch
- sequencer: add "builtin-sequencer--helper.c"
Migrating "rebase -i" bit by bit to C. I am inclined to agree with Dscho
that maybe this approach forces the migration to follow the structure of
the shell script too much, and could force a suboptimal end result, but
we'll see.
* aj/fix-read-tree-from-scratch (2009-08-17) 1 commit
(merged to 'next' on 2009-08-20 at 7a04133)
+ read-tree: Fix regression with creation of a new index file.
Will merge.
* as/maint-graph-interesting-fix (2009-08-18) 1 commit.
- graph API: fix bug in graph_is_interesting()
I need to queue the associated test after getting it signed-off.
* jc/1.7.0-status (2009-08-15) 3 commits
(merged to 'next' on 2009-08-22 at b3507bb)
+ git status: not "commit --dry-run" anymore
+ git stat -s: short status output
+ git stat: the beginning of "status that is not a dry-run of commit"
(this branch uses jc/shortstatus.)
As promised, I squashed incremental "fix-up" into the commits they fix;
this will be kept in 'next' until 1.7.0
* jc/shortstatus (2009-08-15) 11 commits
(merged to 'next' on 2009-08-15 at 7e40766)
+ git commit --dry-run -v: show diff in color when asked
+ Documentation/git-commit.txt: describe --dry-run
(merged to 'next' on 2009-08-12 at 53bda17)
+ wt-status: collect untracked files in a separate "collect" phase
+ Make git_status_config() file scope static to builtin-commit.c
+ wt-status: move wt_status_colors[] into wt_status structure
+ wt-status: move many global settings to wt_status structure
+ commit: --dry-run
(merged to 'next' on 2009-08-06 at fe8cb94)
+ status: show worktree status of conflicted paths separately
+ wt-status.c: rework the way changes to the index and work tree are summarized
+ diff-index: keep the original index intact
+ diff-index: report unmerged new entries
(this branch is used by jc/1.7.0-status.)
Will cook for a bit more and then merge.
* jc/maint-checkout-index-to-prefix (2009-08-16) 1 commit
(merged to 'next' on 2009-08-20 at 2f6aea2)
+ check_path(): allow symlinked directories to checkout-index --prefix
Will merge.
* jc/maint-unpack-objects-strict (2009-08-13) 1 commit.
(merged to 'next' on 2009-08-23 at 38eb750)
+ Fix "unpack-objects --strict"
* jh/submodule-foreach (2009-08-20) 9 commits
(merged to 'next' on 2009-08-20 at 671bea4)
+ git clone: Add --recursive to automatically checkout (nested) submodules
+ t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
(merged to 'next' on 2009-08-18 at f4a881d)
+ git submodule status: Add --recursive to recurse into nested submodules
+ git submodule update: Introduce --recursive to update nested submodules
+ git submodule foreach: Add --recursive to recurse into nested submodules
+ git submodule foreach: test access to submodule name as '$name'
+ Add selftest for 'git submodule foreach'
+ git submodule: Cleanup usage string and add option parsing to cmd_foreach()
+ git submodule foreach: Provide access to submodule name, as '$name'
* jl/submodule-summary-diff-files (2009-08-15) 2 commits
(merged to 'next' on 2009-08-15 at 165bd8e)
+ Documentaqtion/git-submodule.txt: Typofix
(merged to 'next' on 2009-08-14 at a702e78)
+ git submodule summary: add --files option
Will merge.
* lh/short-decorate (2009-08-15) 1 commit
(merged to 'next' on 2009-08-18 at b8c1d96)
+ git-log: allow --decorate[=short|full]
Will merge.
* oa/stash-na (2009-08-11) 1 commit
(merged to 'next' on 2009-08-14 at 12c2e2b)
+ git stash: Give friendlier errors when there is nothing to apply
Will merge.
* jh/notes (2009-07-29) 8 commits.
- t3302-notes-index-expensive: Speed up create_repo()
- fast-import: Add support for importing commit notes
- First draft of notes tree parser with support for fanout subtrees
- Teach "-m <msg>" and "-F <file>" to "git notes edit"
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
The cvs-helper series depends on this one.
* ne/rev-cache (2009-08-21) 6 commits
. support for path name caching in rev-cache
. full integration of rev-cache into git, completed test suite
. administrative functions for rev-cache, start of integration into git
. support for non-commit object caching in rev-cache
. basic revision cache system, no integration or features
. man page and technical discussion for rev-cache
Updated but seems to break tests when merged to 'pu'; didn't look at the
issue deeply.
* jh/cvs-helper (2009-08-18) 7 commits
- More fixes to the git-remote-cvs installation procedure
- Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
- Add simple selftests of git-remote-cvs functionality
- git-remote-cvs: Remote helper program for CVS repositories
- 2/2: Add Python support library for CVS remote helper
- 1/2: Add Python support library for CVS remote helper
- Basic build infrastructure for Python scripts
(this branch uses db/vcs-helper.)
Builds on db/vcs-helper. The testing of Python part seemed to be
still fragile even with the latest fix on one of my boches with an
earlier round already installed, but I didn't look very deeply before
removing the older installation.
* nd/sparse (2009-08-20) 20 commits
- sparse checkout: inhibit empty worktree
- Add tests for sparse checkout
- read-tree: add --no-sparse-checkout to disable sparse checkout support
- unpack-trees(): ignore worktree check outside checkout area
- unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
- unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
- unpack-trees.c: generalize verify_* functions
- unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
- Introduce "sparse checkout"
- dir.c: export excluded_1() and add_excludes_from_file_1()
- excluded_1(): support exclude files in index
- unpack-trees(): carry skip-worktree bit over in merged_entry()
- Read .gitignore from index if it is skip-worktree
- Avoid writing to buffer in add_excludes_from_file_1()
- Teach Git to respect skip-worktree bit (writing part)
- Teach Git to respect skip-worktree bit (reading part)
- Introduce "skip-worktree" bit in index, teach Git to get/set this bit
- Add test-index-version
- update-index: refactor mark_valid() in preparation for new options
(merged to 'next' on 2009-08-20 at ea167d7)
+ Prevent diff machinery from examining assume-unchanged entries on worktree
The first one was an independent fix; the rest has been replaced with the
"return of no-checkout" series.
* jc/1.7.0-diff-whitespace-only-status (2009-05-23) 2 commits.
(merged to 'next' on 2009-08-02 at 9c08420)
+ diff: Rename QUIET internal option to QUICK
+ diff: change semantics of "ignore whitespace" options
For 1.7.0. This changes exit code from "git diff --ignore-whitespace" and
friends when there is no actual output. It is a backward incompatible
change, but we could argue that it is a bugfix.
* jc/1.7.0-push-safety (2009-02-09) 2 commits
(merged to 'next' on 2009-08-02 at 38b82fe)
+ Refuse deleting the current branch via push
+ Refuse updating the current branch in a non-bare repository via push
For 1.7.0.
* jc/log-tz (2009-03-03) 1 commit.
- Allow --date=local --date=other-format to work as expected
* jc/mailinfo-remove-brackets (2009-07-15) 1 commit.
- mailinfo: -b option keeps [bracketed] strings that is not a [PATCH] marker
--------------------------------------------------
[I have been too busy to purge these]
* ar/maint-1.6.2-merge-recursive-d-f (2009-05-11) 2 commits.
. Fix for a merge where a branch has an F->D transition
. Add a reminder test case for a merge with F/D transition
* jc/merge-convert (2009-01-26) 1 commit.
. git-merge-file: allow converting the results for the work tree
* lt/read-directory (2009-05-15) 3 commits.
. Add initial support for pathname conversion to UTF-8
. read_directory(): infrastructure for pathname character set conversion
. Add 'fill_directory()' helper function for directory traversal
* ps/blame (2009-03-12) 1 commit.
. blame.c: start libifying the blame infrastructure
* pb/tracking (2009-07-16) 7 commits.
. branch.c: if remote is not config'd for branch, don't try delete push config
. branch, checkout: introduce autosetuppush
. move deletion of merge configuration to branch.c
. remote: add per-remote autosetupmerge and autosetuprebase configuration
. introduce a struct tracking_config
. branch: install_branch_config and struct tracking refactoring
. config: allow false and true values for branch.autosetuprebase
Has been ejected from 'pu' for some time, expecting a reroll.
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Nicolas Pitre @ 2009-08-24 1:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vn2qb29.fsf@alter.siamese.dyndns.org>
On Sun, 23 Aug 2009, Junio C Hamano wrote:
> * lt/block-sha1 (2009-08-17) 4 commits
> (merged to 'next' on 2009-08-18 at 67a1ce8)
> + remove ARM and Mozilla SHA1 implementations
> + block-sha1: guard gcc extensions with __GNUC__
> + make sure byte swapping is optimal for git
> + block-sha1: make the size member first in the context struct
>
> Finishing touches ;-) There were a few Solaris portability patches
> floated around that I didn't pick up, waiting for them to finalize.
Those would be described better as Solaris _optimization_ patches. The
code is already fully portable as it is, except not necessarily optimal
in some cases.
Nicolas
^ permalink raw reply
* [RFC/PATCH 1/3] gitweb: improve snapshot error handling
From: Mark Rada @ 2009-08-24 3:09 UTC (permalink / raw)
To: Sam Vilain; +Cc: Mark Rada, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <4A91C74D.1080908@vilain.net>
Ok, this is just a resend of the first patch in my set from
earlier, but with some of the commit message reworded, namely
the subject (as suggested by Sam Vilain).
--
Mark Rada (ferrous26)
marada@uwaterloo.ca
--->8---
In the second block of checks to validate a snapshot request, the last
check is never executed because the second last check is a superset of
the last check.
This change will switch the order of the last two checks, it has the
advantage of giving clients a more specific reason why they cannot get
a snapshot format if the format they have chosen is disabled.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
---
gitweb/gitweb.perl | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 4a42f61..7068db2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5174,10 +5174,10 @@ sub git_snapshot {
die_error(400, "Invalid snapshot format parameter");
} elsif (!exists($known_snapshot_formats{$format})) {
die_error(400, "Unknown snapshot format");
- } elsif (!grep($_ eq $format, @snapshot_fmts)) {
- die_error(403, "Unsupported snapshot format");
} elsif ($known_snapshot_formats{$format}{'disabled'}) {
die_error(403, "Snapshot format not allowed");
+ } elsif (!grep($_ eq $format, @snapshot_fmts)) {
+ die_error(403, "Unsupported snapshot format");
}
if (!defined $hash) {
--
1.6.4
^ permalink raw reply related
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-24 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vzl9qtev0.fsf@alter.siamese.dyndns.org>
Junio C Hamano (gitster@pobox.com) wrote on Aug 23, 2009:
> Thell Fowler <git@tbfowler.name> writes:
>
> >> Or we can just move the final else clause up and start the function like
> >> this:
> >>
> >> int i1, i2;
> >>
> >> if (!(flags & XDF_WHITESPACE_FLAGS))
> >> return s1 == s2 && !memcmp(l1, l2, s1);
> >>
> >> i1 = i2 = 0;
> >> if (flags & XDF_IGNORE_WHITESPACE) {
> >> ...
> >>
> >> that would get rid of two unnecessary clearing of variables (i1 and i2,
> >> even though I suspect that the compiler _could_ optimize them out without
> >> such an change), and three flags-bit check in the most common case of not
> >> ignoring any whitespaces.
> >>
> >
> > HA! That's a nifty way to do that with the variables.
>
> My tentative draft to replace the "how about this" patch further reworks
> the loop structure and currently looks like this.
>
> It adds net 15 lines but among that 12 lines are comments, which is not so
> bad.
>
It passed every test I threw at it, although it seemed to be a tad bit
slower than the previous revision on my sample data so I ran the following
command several times for both the previous and current version:
time for i in {1..10}; do ./t4015-diff-whitespace.sh>/dev/null &&
./t4015-diff-trailing-whitespace.sh >/dev/null; done
And these results are fairly average on what I saw:
Previous version:
real 2m32.669s
user 0m44.051s
sys 1m34.702s
Current version:
real 2m56.818s
user 0m47.671s
sys 1m46.723s
--
Thell
^ permalink raw reply
* [PATCH] fix simple deepening of a repo
From: Nicolas Pitre @ 2009-08-24 4:04 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0908220106470.6044@xanadu.home>
If all refs sent by the remote repo during a fetch are reachable
locally, then no further conversation is performed with the remote. This
check is skipped when the --depth argument is provided to allow the
deepening of a shallow clone which corresponding remote repo has no
changed.
However, some additional filtering was added in commit c29727d5 to
remove those refs which are equal on both sides. If the remote repo has
not changed, then the list of refs to give the remote process becomes
empty and simply attempting to deepen a shallow repo always fails.
Let's stop being smart in that case and simply send the whole list over
when that condition is met. The remote will do the right thing anyways.
Test cases for this issue are also provided.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Sat, 22 Aug 2009, Nicolas Pitre wrote:
> try out:
>
> git clone --depth=1 git://git.kernel.org/pub/scm/git/git
> cd git
> git fetch --depth=2
>
> It then silently fails, except for the return code of 1.
Here's the fix. Problem wasn't in builtin-fetch-pack.c after all.
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index a8c2ca2..18376d6 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -139,6 +139,36 @@ test_expect_success 'fsck in shallow repo' '
)
'
+test_expect_success 'simple fetch in shallow repo' '
+ (
+ cd shallow &&
+ git fetch
+ )
+'
+
+test_expect_success 'no changes expected' '
+ (
+ cd shallow &&
+ git count-objects -v
+ ) > count.shallow.2 &&
+ cmp count.shallow count.shallow.2
+'
+
+test_expect_success 'fetch same depth in shallow repo' '
+ (
+ cd shallow &&
+ git fetch --depth=2
+ )
+'
+
+test_expect_success 'no changes expected' '
+ (
+ cd shallow &&
+ git count-objects -v
+ ) > count.shallow.3 &&
+ cmp count.shallow count.shallow.3
+'
+
test_expect_success 'add two more' '
add B66 $B65 &&
add B67 $B66
@@ -201,4 +231,21 @@ test_expect_success 'pull in shallow repo with missing merge base' '
)
'
+test_expect_success 'additional simple shallow deepenings' '
+ (
+ cd shallow &&
+ git fetch --depth=8 &&
+ git fetch --depth=10 &&
+ git fetch --depth=11
+ )
+'
+
+test_expect_success 'clone shallow object count' '
+ (
+ cd shallow &&
+ git count-objects -v
+ ) > count.shallow &&
+ grep "^count: 52" count.shallow
+'
+
test_done
diff --git a/transport.c b/transport.c
index a8df319..ce91387 100644
--- a/transport.c
+++ b/transport.c
@@ -925,11 +925,12 @@ const struct ref *transport_get_remote_refs(struct transport *transport)
int transport_fetch_refs(struct transport *transport, const struct ref *refs)
{
int rc;
- int nr_heads = 0, nr_alloc = 0;
+ int nr_heads = 0, nr_alloc = 0, nr_refs = 0;
const struct ref **heads = NULL;
const struct ref *rm;
for (rm = refs; rm; rm = rm->next) {
+ nr_refs++;
if (rm->peer_ref &&
!hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
continue;
@@ -937,6 +938,19 @@ int transport_fetch_refs(struct transport *transport, const struct ref *refs)
heads[nr_heads++] = rm;
}
+ if (!nr_heads) {
+ /*
+ * When deepening of a shallow repository is requested,
+ * then local and remote refs are likely to still be equal.
+ * Just feed them all to the fetch method in that case.
+ * This condition shouldn't be met in a non-deepening fetch
+ * (see builtin-fetch.c:quickfetch()).
+ */
+ heads = xmalloc(nr_refs * sizeof(*heads));
+ for (rm = refs; rm; rm = rm->next)
+ heads[nr_heads++] = rm;
+ }
+
rc = transport->fetch(transport, nr_heads, heads);
free(heads);
return rc;
^ permalink raw reply related
* Re: [PATCH] remove ARM and Mozilla SHA1 implementations
From: Nicolas Pitre @ 2009-08-24 4:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0908180208160.8306@pacific.mpi-cbg.de>
On Tue, 18 Aug 2009, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Aug 2009, Nicolas Pitre wrote:
>
> > They are both slower than the new BLK_SHA1 implementation, so it is
> > pointless to keep them around.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
> >
> > Someone else would need to make the call for the PPC version.
>
> If I don't forget, I can test tomorrow on 2 different 32-bit PPCs and
> possibly one 64-bit PPC.
Did you forget? ;-)
Nicolas
^ permalink raw reply
* [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 4:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thell Fowler, Nanako Shiraishi, git, Johannes.Schindelin
In-Reply-To: <7v7hwurwmu.fsf@alter.siamese.dyndns.org>
Subject: [PATCH] Wong title
From: is this one really the author? <email@somebody.dom>
The 23/08/09, Junio C Hamano wrote:
>
> >> > Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
>
> The one I sent out had two bugs. Please discard and replace it with a
> newer one I'll be pushing out on 'pu' later today.
( Tested against current 925bd84 in pu. )
If we have a mail with this form
<header>
Subject: [PATCH] BLAH ONE
</header>
Subject: [PATCH] BLAH TWO
<...>
-- >8 --
Subject: [PATCH] BLAH THREE
the commit message looks like
BLAH TWO
Subject: [PATCH] BLAH THREE
I'd expect that we take the "Subject: " line after the mark and fallback
to the header if missing.
Same applies to the "From: " lines.
This mail should be usable to your own tests.
-- >8 -- Please squash this to 925bd84 -- >8 --
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..0c9a791 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -138,6 +138,9 @@ The commit message is formed by the title taken from
the
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
+If a line starts with a "-- >8 --" mark in the body of the message,
+everything before (and the line itself) will be ignored.
+
The patch is expected to be inline, directly following the
message. Any line that is of the form:
--
Nicolas Sebrecht
^ permalink raw reply related
* Re: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-24 4:49 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.2.00.0908232320410.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> If all refs sent by the remote repo during a fetch are reachable
> locally, then no further conversation is performed with the remote. This
> check is skipped when the --depth argument is provided to allow the
> deepening of a shallow clone which corresponding remote repo has no
> changed.
>
> However, some additional filtering was added in commit c29727d5 to
> remove those refs which are equal on both sides. If the remote repo has
> not changed, then the list of refs to give the remote process becomes
> empty and simply attempting to deepen a shallow repo always fails.
>
> Let's stop being smart in that case and simply send the whole list over
> when that condition is met. The remote will do the right thing anyways.
>
> Test cases for this issue are also provided.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
Thanks. The fix looks correct (as usual with patches from you).
But it makes me wonder if this logic to filter refs is buying us anything.
> for (rm = refs; rm; rm = rm->next) {
> + nr_refs++;
> if (rm->peer_ref &&
> !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
> continue;
ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
heads[nr_heads++] = rm;
}
What is the point of not asking for the refs that we know are the same?
In other words, what breaks (not necessarily in the correctness sense, but
also in the performance sense) if we get rid of this filtering altogether?
Over a native protocol, we will tell the other end what we have and the
remote end will notice that we are asking for the same thing, so it won't
include unnecessary objects in the pack anyway. When calling out to a
walker, we will also notice that the ref matches what we have already and
will not fetch anything from the remote. Because the commit at the tip of
the ref that is already up-to-date is marked as COMPLETE, we will not even
locally have to walk the object chain to make sure things are connected.
I think the only thing that this possibly gains is if _everything_ is up
to date. Then we won't need to make a call to transport->fetch() and it
would save a new connection.
But that optimization is already done long ago by the caller's
quickfetch() in the normal case.
Which makes me suspect that the real fix should be something a lot
simpler, like this (untested) patch.
diff --git a/transport.c b/transport.c
index f231b35..14dab81 100644
--- a/transport.c
+++ b/transport.c
@@ -1053,18 +1053,16 @@ const struct ref *transport_get_remote_refs(struct transport *transport)
int transport_fetch_refs(struct transport *transport, const struct ref *refs)
{
int rc;
- int nr_heads = 0, nr_alloc = 0;
+ int nr_heads = 0;
const struct ref **heads = NULL;
const struct ref *rm;
- for (rm = refs; rm; rm = rm->next) {
- if (rm->peer_ref &&
- !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
- continue;
- ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
+ for (rm = refs; rm; rm = rm->next)
+ nr_heads++;
+ heads = xmalloc(nr_heads * sizeof(*heads));
+ nr_heads = 0;
+ for (rm = refs; rm; rm = rm->next)
heads[nr_heads++] = rm;
- }
-
rc = transport->fetch(transport, nr_heads, heads);
free(heads);
return rc;
^ permalink raw reply related
* Re: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 4:51 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <20090824041608.GC3526@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> I'd expect that we take the "Subject: " line after the mark and fallback
> to the header if missing.
Patches welcome.
^ permalink raw reply
* Re: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Nanako Shiraishi @ 2009-08-24 5:16 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Junio C Hamano, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824041608.GC3526@vidovic>
Quoting Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
> index fcacc94..0c9a791 100644
> --- a/Documentation/git-am.txt
> +++ b/Documentation/git-am.txt
> @@ -138,6 +138,9 @@ The commit message is formed by the title taken from
> the
> where the patch begins. Excess whitespace at the end of each
> line is automatically stripped.
>
> +If a line starts with a "-- >8 --" mark in the body of the message,
> +everything before (and the line itself) will be ignored.
Looking at the way other people use the mark in their messages, I think this explanation isn't correct.
A scissors mark doesn't have to be at the beginning. The line has to contain the mark, and it has to consist of only the mark, '-' minus, the phrase "cut here", and whitespaces.
I am not familiar enough with the code to comment on the bug you are reporting.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 5:36 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Thell Fowler, Nanako Shiraishi, git, Johannes.Schindelin
In-Reply-To: <7vk50tq0g5.fsf@alter.siamese.dyndns.org>
Try this patch, perhaps? I forgot to reset the mysteriously named s_hdr
buffer.
Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
the way?
-- >8 -- cut here -- >8 --
Subject: [PATCH] squashme to 925bd84 (Teach mailinfo to ignore everything before -- >8 -- mark, 2009-08-23)
builtin-mailinfo.c | 6 ++++++
t/t5100/sample.mbox | 4 ++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 26548f0..8a3a184 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -758,9 +758,15 @@ static int handle_commit_msg(struct strbuf *line)
}
if (scissors(line)) {
+ int i;
rewind(cmitmsg);
ftruncate(fileno(cmitmsg), 0);
still_looking = 1;
+ for (i = 0; header[i]; i++) {
+ if (s_hdr_data[i])
+ strbuf_release(s_hdr_data[i]);
+ s_hdr_data[i] = NULL;
+ }
return 0;
}
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 95b6842..2c3da52 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -566,10 +566,14 @@ From: Junio Hamano <junkio@cox.net>
Date: Thu, 20 Aug 2009 17:18:22 -0700
Subject: Why doesn't git-am does not like >8 scissors mark?
+Subject: [PATCH] BLAH ONE
+
In real life, we will see a discussion that inspired this patch
discussing related and unrelated things around >8 scissors mark
in this part of the message.
+Subject: [PATCH] BLAH TWO
+
And the we will see the scissors.
-- >8 -- cut here -- 8< --
^ permalink raw reply related
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Junio C Hamano @ 2009-08-24 6:02 UTC (permalink / raw)
To: Thell Fowler; +Cc: git, Johannes.Schindelin
In-Reply-To: <alpine.DEB.2.00.0908232044060.29625@GWPortableVCS>
Thell Fowler <git@tbfowler.name> writes:
> It passed every test I threw at it, although it seemed to be a tad bit
> slower than the previous revision on my sample data so I ran the following
> command several times for both the previous and current version:
>
> time for i in {1..10}; do ./t4015-diff-whitespace.sh>/dev/null &&
> ./t4015-diff-trailing-whitespace.sh >/dev/null; done
>
> And these results are fairly average on what I saw:
>
> Previous version:
> real 2m32.669s
> user 0m44.051s
> sys 1m34.702s
>
>
> Current version:
> real 2m56.818s
> user 0m47.671s
> sys 1m46.723s
Do you mean by "previous version" the one that was broken, or the one I
sent as a "how about" patch?
Here are the numbers I am getting:
$ /usr/bin/time sh -c 'for i in 1 2 3 4 5 6 7 8 9 0; do ./t4015-diff-whitespace.sh; done' >/dev/null
----------------
1.99user 3.65system 0:05.10elapsed 110%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288675minor)pagefaults 0swaps
1.86user 3.66system 0:05.04elapsed 109%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288618minor)pagefaults 0swaps
1.76user 3.87system 0:05.02elapsed 112%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288973minor)pagefaults 0swaps
----------------
1.81user 3.86system 0:05.08elapsed 111%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288836minor)pagefaults 0swaps
1.76user 3.87system 0:04.95elapsed 113%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288880minor)pagefaults 0swaps
1.81user 3.88system 0:05.04elapsed 112%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+12560outputs (0major+1288530minor)pagefaults 0swaps
----------------
One set is with patch and one set is the patch reverted. I cannot quite
remember which one is which ;-) but the difference is within the noise for me.
I have to revisit this sometime after getting a long rest.
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 6:21 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <7vmy5pojsg.fsf@alter.siamese.dyndns.org>
The 23/08/09, Junio C Hamano wrote:
> Try this patch, perhaps? I forgot to reset the mysteriously named s_hdr
> buffer.
Nice. Please add
Tested-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
> the way?
Has been added by 87ab799234639c .
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 6:22 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090824060710.6117@nanako3.lavabit.com>
Nanako Shiraishi wrote:
> Quoting Sanjiv Gupta <sanjiv.gupta@microchip.com>
>
>
>> I just wanted to know how can I pull one commit at a time from public
>> repository.
>> e.g.
>> when I first cloned from the public repo, it was at X. now it has
>> reached Y. I just want to pull x+1.
>>
>
> When your histories look like this:
>
> A your 'master'
> /
> ---X---U---V---W---Y public 'master' (your 'origin')
>
> instead of creating a single merge like this with "git pull":
>
> A---------------M your 'master' (fully merges 'origin')
> / /
> ---X---U---V---W---Y public 'master'
>
> you want to create a history like this?
>
> A---J your 'master' (lacks V, W and Y)
> / /
> ---X---U---V---W---Y public 'master'
>
> For that, you can fetch first.
>
> git fetch origin
>
> Then look at the history in gitk
>
> gitk master origin
>
> And find the commit you are interested in merging (U in the above picture). And merge it.
>
> git merge origin~3
>
> Replace "origin~3" in the example above with whatever commit you want to merge the entire history leading to it.
>
> You can repeat this final step as many times you want. For example, if you want create a history like this:
>
> A---J---K---L---M your 'master'
> / / / / /
> ---X---U---V---W---Y public 'master'
>
> you can do so by repeating the last step for V, W and Y in turn.
>
> In general the public history isn't necessarily a single straight line like this picture and it doesn't make sense to merge one at a time for all the commits on the public branch, but if that is what you really want to do, you can do so.
>
>
Excellent description. Thanks for that. I want to merge commits one by
one because I want to run a regression suite on each commit and
therefore know if any one is causing failures.
- Sanjiv
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 6:58 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Junio C Hamano, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin
In-Reply-To: <20090824062141.GD3526@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
>> the way?
>
> Has been added by 87ab799234639c .
That much I know ;-), thanks anyway.
The commit does not _explain_ what they are for, what they mean, and what
these mysteriously named variables do.
^ permalink raw reply
* Re: [msysGit] Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Marius Storm-Olsen @ 2009-08-24 7:03 UTC (permalink / raw)
To: Thiago Farina
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git,
lznuaa
In-Reply-To: <a4c8a6d00908231229v56eceeddue1b927a4e4e49ee3@mail.gmail.com>
Thiago Farina said the following on 23.08.2009 21:29:
> Marius, how common-cmds.h will be generated? In the header file says
> that it's generated by generate-cmdlist.sh, so the VS user will need
> to generate this file first (before compiling)?
> When I tried to compile after pulling from the repository, I couldn't,
> so I copied it from the the msysgit.
The easiest is just do the following on the command line, provided
that you have the msysgit environment available (so GNU Make etc):
make common-cmds.h
That will ensure that the file is generated correctly. After that you
can build with msvc, based on the patch series.
--
.marius
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:17 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Nicolas Sebrecht, Junio C Hamano, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <20090824141623.6117@nanako3.lavabit.com>
[ Please, please, please, wrap your lines. ]
The 24/08/09, Nanako Shiraishi wrote:
> Looking at the way other people use the mark in their messages, I think this explanation isn't correct.
I'd say that should not document what people do but what the program
does.
> A scissors mark doesn't have to be at the beginning. The line has to contain the mark, and it has to consist of only the mark, '-' minus, the phrase "cut here", and whitespaces.
...and (">8" or "<8"), you're right. But isn't the following mark a bit
too much permissive?
->8
Subject: [PATCH] squashable to 925bd84 (Teach mailinfo to ignore everything before -- >8 -- mark, 2009-08-23)
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
This patch supersedes my previous round.
Documentation/git-am.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..1d10371 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -138,6 +138,10 @@ The commit message is formed by the title taken
from the
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
+If a line starts with a "-- >8 --" mark in the body of the message,
+everything before (and the line itself) will be ignored.
+Whitespaces and strings "cut here" are tolerated.
+
The patch is expected to be inline, directly following the
message. Any line that is of the form:
--
Nicolas Sebrecht
^ permalink raw reply related
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:24 UTC (permalink / raw)
To: Nicolas Sebrecht
Cc: Nanako Shiraishi, Junio C Hamano, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <20090824071711.GE3526@vidovic>
( Paste error, sorry. )
The 24/08/09, Nicolas Sebrecht wrote:
> [ Please, please, please, wrap your lines. ]
>
> The 24/08/09, Nanako Shiraishi wrote:
>
> > Looking at the way other people use the mark in their messages, I think this explanation isn't correct.
>
> I'd say that should not document what people do but what the program
> does.
>
> > A scissors mark doesn't have to be at the beginning. The line has to contain the mark, and it has to consist of only the mark, '-' minus, the phrase "cut here", and whitespaces.
>
> ...and (">8" or "<8"), you're right. But isn't the following mark a bit
> too much permissive?
->8
Subject: [PATCH] squashme to 925bd84 (Teach mailinfo to ignore everything before -- >8 -- mark, 2009-08-23)
---
Documentation/git-am.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..5294d47 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -138,6 +138,12 @@ The commit message is formed by the title taken
from the
where the patch begins. Excess whitespace at the end of each
line is automatically stripped.
+If a line contains a mark in the body of the message, everything
+before (and the line itself) will be ignored. A mark has typically
+the form "-- >8 -- cut here -- >8 --". Strictly speacking, it must
+have one dash at least and a ">8" (or "<8"). Spaces and strings
+"cut here" are permited.
+
The patch is expected to be inline, directly following the
message. Any line that is of the form:
--
Nicolas Sebrecht
^ permalink raw reply related
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-24 7:31 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Thell Fowler, Nanako Shiraishi, git,
Johannes.Schindelin, Don Zickus
In-Reply-To: <7v7hwtofys.fsf@alter.siamese.dyndns.org>
( cc'ing Don Zickus )
The 23/08/09, Junio C Hamano wrote:
> Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>
> >> Does anybody remember what these s_hdr (vs p_hdr) buffers stand for, by
> >> the way?
> >
> > Has been added by 87ab799234639c .
>
> That much I know ;-), thanks anyway.
>
> The commit does not _explain_ what they are for, what they mean, and what
> these mysteriously named variables do.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Kai Blin @ 2009-08-24 7:46 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Nanako Shiraishi, git
In-Reply-To: <4A92318F.6050105@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 2351 bytes --]
On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:
> > In general the public history isn't necessarily a single straight line
> > like this picture and it doesn't make sense to merge one at a time for
> > all the commits on the public branch, but if that is what you really want
> > to do, you can do so.
>
> Excellent description. Thanks for that. I want to merge commits one by
> one because I want to run a regression suite on each commit and
> therefore know if any one is causing failures.
What I do for a case like this is using rebase. I'm not sure if I get the
explanation right enough to please all the git gurus on the list, but I'll
try. What this basically does is to back out all the commits you did on your
branch to the point you diverged from the branch you're rebasing on now.
So assuming you had a structure like this:
your 'master' HEAD
|
A---B---C
/
---X---U---V---W---Y
|
public 'master' HEAD
git would back out commits A-C, so your local branch HEAD would be at X. Then,
if forwards your branch to the branch you're rebasing on, so your local
branch HEAD is at Y now, like the public branch HEAD.
After that, git applies all of your patches back to your local branch,
producing a tree that looks like this:
your 'master' HEAD
|
A---B---C
/
---X---U---V---W---Y
|
public 'master' head
Personally I prefer that solution as it keeps the history linear. Of course
this means that all of your commits change sha1s, and you should not do this
on public branches with tags. But if you're still developing, it's much
easier to wrap your head around a history like this. It's also nice to
present feature branches to other people, as all of your commits are in one
block, without lots of annoying merge commits between them.
rebase also handles more complicated cases of merging, but from the way I
understood your issue, this should already help.
Cheers,
Kai
--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sanjiv Gupta @ 2009-08-24 7:55 UTC (permalink / raw)
To: Kai Blin; +Cc: Nanako Shiraishi, git
In-Reply-To: <200908240946.52813.kai@samba.org>
Kai Blin wrote:
> On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:
>
>
>>> In general the public history isn't necessarily a single straight line
>>> like this picture and it doesn't make sense to merge one at a time for
>>> all the commits on the public branch, but if that is what you really want
>>> to do, you can do so.
>>>
>> Excellent description. Thanks for that. I want to merge commits one by
>> one because I want to run a regression suite on each commit and
>> therefore know if any one is causing failures.
>>
>
> What I do for a case like this is using rebase. I'm not sure if I get the
> explanation right enough to please all the git gurus on the list, but I'll
> try. What this basically does is to back out all the commits you did on your
> branch to the point you diverged from the branch you're rebasing on now.
>
> So assuming you had a structure like this:
>
> your 'master' HEAD
> |
> A---B---C
> /
> ---X---U---V---W---Y
> |
> public 'master' HEAD
>
> git would back out commits A-C, so your local branch HEAD would be at X. Then,
> if forwards your branch to the branch you're rebasing on, so your local
> branch HEAD is at Y now, like the public branch HEAD.
>
> After that, git applies all of your patches back to your local branch,
> producing a tree that looks like this:
>
> your 'master' HEAD
> |
> A---B---C
> /
> ---X---U---V---W---Y
> |
> public 'master' head
>
> Personally I prefer that solution as it keeps the history linear. Of course
> this means that all of your commits change sha1s, and you should not do this
> on public branches with tags. But if you're still developing, it's much
> easier to wrap your head around a history like this. It's also nice to
> present feature branches to other people, as all of your commits are in one
> block, without lots of annoying merge commits between them.
>
> rebase also handles more complicated cases of merging, but from the way I
> understood your issue, this should already help.
>
> Cheers,
> Kai
>
Thanks Kai.
What I would like is to "test *every* commit" available in the public
master. There would be no local changes or commits that aren't pushed in
the private copy.
So I just want to clone one copy from the public master and then just
keep pulling commits from the public master one by one and run
regressions on each one.
It's a damn simple thing in SVN world.
$ svn info will give you the current version you are at, assume it is
"cur_rev"
$ svn update -r `expr $cur_rev + 1`
$ build
$ test
Thanks,
- Sanjiv
^ permalink raw reply
* Re: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Nanako Shiraishi @ 2009-08-24 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Sebrecht, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824141623.6117@nanako3.lavabit.com>
Quoting myself...
> A scissors mark doesn't have to be at the beginning. The line has to
> contain the mark, and it has to consist of only the mark, '-' minus, the
> phrase "cut here", and whitespaces.
Junio, perhaps you want to squash some documentation, too.
-- 8< -- cut here -- 8< -- cut here -- 8< --
Subject: [PATCH] Documentation: describe the scissors mark support of "git am"
Describe what a scissors mark looks like, and explain in what situation
it is often used.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Documentation/git-am.txt | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..fecd5ac 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -128,10 +128,18 @@ the commit, after stripping common prefix "[PATCH <anything>]".
The "Subject: " line is supposed to concisely describe what the
commit is about in one line of text.
-"From: " and "Subject: " lines starting the body (the rest of the
-message after the blank line terminating the RFC2822 headers)
-override the respective commit author name and title values taken
-from the headers.
+A line that contains a scissors mark (either ">8" or "8<") and does not
+have anything other than scissors, dash (-), whitespaces or a phrase "cut
+here" is called a scissors line. If such a line appears in the body of the
+message before the patch, everything before it (including the scissors
+line itself) is ignored. This is useful if you want to begin your message
+in a discussion thread with comments and suggestions on the message you
+are responding to, and to conclude it with a patch submission, separating
+the discussion and the beginning of the proposed commit log message with a
+scissors line.
+
+"From: " and "Subject: " lines starting the body override the respective
+commit author name and title values taken from the headers.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: Pulling one commit at a time.
From: Erik Faye-Lund @ 2009-08-24 8:20 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
On Mon, Aug 24, 2009 at 9:55 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:
> It's a damn simple thing in SVN world.
> $ svn info will give you the current version you are at, assume it is
> "cur_rev"
> $ svn update -r `expr $cur_rev + 1`
> $ build
> $ test
I guess you could do it something like this. Unlike your example, this
processes all new commits, not just the next one.
$ git fetch origin master
$ for c in $(git rev-list HEAD..FETCH_HEAD); do
$ git checkout $c
$ build
$ test
$ done
$ git merge FETCH_HEAD
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Erik Faye-Lund @ 2009-08-24 8:22 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <40aa078e0908240120o36004f78m52aa34c8a338854c@mail.gmail.com>
> $ git merge FETCH_HEAD
Uhm, of course, you'd have to reattach HEAD to your branch before
merging. My bad ;)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: Pulling one commit at a time.
From: Sean Estabrooks @ 2009-08-24 8:20 UTC (permalink / raw)
To: Sanjiv Gupta; +Cc: Kai Blin, Nanako Shiraishi, git
In-Reply-To: <4A92476A.4060205@microchip.com>
On Mon, 24 Aug 2009 13:25:22 +0530
Sanjiv Gupta <sanjiv.gupta@microchip.com> wrote:
Hi Sanjiv,
> What I would like is to "test *every* commit" available in the public
> master. There would be no local changes or commits that aren't pushed in
> the private copy.
> So I just want to clone one copy from the public master and then just
> keep pulling commits from the public master one by one and run
> regressions on each one.
There's no reason to ask for the commits from the public master one by
one. You can download them all in one operation. After that it is
a local operation to checkout each new commit and build-test it. This
is more efficient than needing a network operation to get each commit
individually.
As an aside, you might not really need to test each and every commit.
It is likely enough to just test the most recent commit since it is
built on top of all the commits that came before it. Essentially
you'd be testing all the new commits at once and only need to test
more commits (git bisect) if you found a regression with that first
test.
> It's a damn simple thing in SVN world.
With Git you have a complete local copy of the history. Once you're
up to date with remote master you can checkout each new commit at
your leisure pretty damn simply ;o)
Cheers,
Sean
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox