* What's cooking in git.git (Jan 2010, #05; Sat, 16)
From: Junio C Hamano @ 2010-01-17 2:46 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.
I am expecting that the next week we will see quite a busy 'master', as I
would really like to close the merge window for 1.7.0 and tag -rc0 by the
end of it.
--------------------------------------------------
[New Topics]
* dp/maint-1.6.5-fast-import-non-commit-tag (2010-01-14) 1 commit
(merged to 'next' on 2010-01-16 at f95ea8e)
+ fast-import: tag may point to any object type
* il/push-set-upstream (2010-01-16) 1 commit
(merged to 'next' on 2010-01-16 at e3a7a60)
+ Add push --set-upstream
* js/windows (2010-01-15) 7 commits
- Do not use date.c:tm_to_time_t() from compat/mingw.c
- MSVC: Windows-native implementation for subset of Pthreads API
- MSVC: Fix an "incompatible pointer types" compiler warning
- Windows: avoid the "dup dance" when spawning a child process
- Windows: simplify the pipe(2) implementation
- Windows: boost startup by avoiding a static dependency on shell32.dll
- Windows: disable Python
* nd/status-partial-refresh (2010-01-14) 1 commit
(merged to 'next' on 2010-01-16 at f77bc8f)
+ status: only touch path we may need to check
* rr/core-tutorial (2010-01-16) 1 commit
(merged to 'next' on 2010-01-16 at d9dd8bd)
+ Documentation: Update git core tutorial clarifying reference to scripts
* jc/conflict-mark-len-attr (2010-01-16) 3 commits
. WIP : honor conflict-marker-lenght in rerere (does not work yet)
. rerere: use ll_merge() instead of using xdl_merge()
. conflict-marker-length: new attribute
(this branch uses jc/cache-unmerge.)
I am attempting to introduce a new per-path attribute to specify
non-default conflict marker length to help rerere grok conflicts in
Documentation/git-merge.txt, but the series is not yet in a presentable
state yet.
--------------------------------------------------
[Stalled]
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* js/refer-upstream (2009-09-10) 1 commit
- Introduce <branch>@{upstream} notation
This does not teach the public interface about the new syntax; callers
that care about distinction between name vs SHA-1 might not work as well
as they should.
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
(merged to 'next' on 2010-01-02 at ae42130)
+ Add more testcases to test fast-import of notes
+ Rename t9301 to t9350, to make room for more fast-import tests
+ fast-import: Proper notes tree manipulation
http://thread.gmane.org/gmane.comp.version-control.git/134738
What's the status of the fourth and later patches on this topic? Overall
it looked reasonable, if I recall correctly what I thought when I reviewed
it last time, and I am tempted to merge it to 'next' soonish. Please
file complaints before I do so if people have objections.
Hold: JH on 2010-01-05, http://article.gmane.org/gmane.comp.version-control.git/136183
--------------------------------------------------
[Will merge to 'master' soon unless somebody complains]
* jk/warn-author-committer-after-commit (2010-01-13) 4 commits
(merged to 'next' on 2010-01-16 at f22c077)
+ commit: allow suppression of implicit identity advice
+ commit: show interesting ident information in summary
+ strbuf: add strbuf_addbuf_percentquote
+ strbuf_expand: convert "%%" to "%"
* tr/http-push-ref-status (2010-01-08) 6 commits
(merged to 'next' on 2010-01-16 at 7e872ac)
+ transport-helper.c::push_refs(): emit "no refs" error message
+ transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
+ transport.c::transport_push(): make ref status affect return value
+ refactor ref status logic for pushing
+ t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
+ t5541-http-push.sh: add tests for non-fast-forward pushes
* sr/gfi-options (2009-12-04) 7 commits
(merged to 'next' on 2010-01-10 at 8b305fb)
+ fast-import: add (non-)relative-marks feature
+ fast-import: allow for multiple --import-marks= arguments
+ fast-import: test the new option command
+ fast-import: add option command
+ fast-import: add feature command
+ fast-import: put marks reading in its own function
+ fast-import: put option parsing code in separate functions
* tc/smart-http-restrict (2010-01-14) 5 commits
(merged to 'next' on 2010-01-16 at 71fc84c)
+ Test t5560: Fix test when run with dash
(merged to 'next' on 2010-01-06 at 82736cb)
+ Smart-http tests: Test http-backend without curl or a webserver
+ Smart-http tests: Break test t5560-http-backend into pieces
+ Smart-http tests: Improve coverage in test t5560
+ Smart-http: check if repository is OK to export before serving it
* tc/clone-v-progress (2009-12-26) 4 commits
(merged to 'next' on 2010-01-10 at ec2bfd7)
+ clone: use --progress to force progress reporting
+ clone: set transport->verbose when -v/--verbose is used
+ git-clone.txt: reword description of progress behaviour
+ check stderr with isatty() instead of stdout when deciding to show progress
Perhaps needs an entry in the Release Notes, but otherwise looked Ok.
* jk/run-command-use-shell (2010-01-01) 8 commits
(merged to 'next' on 2010-01-10 at 7479e2a)
+ t4030, t4031: work around bogus MSYS bash path conversion
+ diff: run external diff helper with shell
+ textconv: use shell to run helper
+ editor: use run_command's shell feature
+ run-command: optimize out useless shell calls
+ run-command: convert simple callsites to use_shell
+ t0021: use $SHELL_PATH for the filter script
+ run-command: add "use shell" option
Shuffled the commits in the topic, following J6t's suggestion in
http://thread.gmane.org/gmane.comp.version-control.git/136128
* jn/makefile (2010-01-06) 4 commits
(merged to 'next' on 2010-01-10 at f5a5d42)
+ Makefile: consolidate .FORCE-* targets
+ Makefile: learn to generate listings for targets requiring special flags
+ Makefile: use target-specific variable to pass flags to cc
+ Makefile: regenerate assembler listings when asked
* jc/maint-1.6.1-checkout-m-custom-merge (2010-01-06) 1 commit
(merged to 'next' on 2010-01-10 at df14116)
+ checkout -m path: fix recreating conflicts
* bk/fix-relative-gitdir-file (2010-01-08) 2 commits
(merged to 'next' on 2010-01-16 at cc4ae57)
+ Handle relative paths in submodule .git files
+ Test update-index for a gitlink to a .git file
* jh/commit-status (2010-01-13) 2 commits
(merged to 'next' on 2010-01-13 at 0905d59)
+ t7502: test commit.status, --status and --no-status
+ commit: support commit.status, --status, and --no-status
I have already given ample time for people to react, but ended up getting
tired of waiting for tests to materialize and doing it myself, as I want
to close merge window for 1.7.0-rc0 by the end of next week to have the
final release early next month.
* sd/cd-p-show-toplevel (2010-01-12) 2 commits
(merged to 'next' on 2010-01-16 at 57d6d31)
+ Use $(git rev-parse --show-toplevel) in cd_to_toplevel().
+ Add 'git rev-parse --show-toplevel' option.
Avoid having to use "cd -P" that may not be available on some platforms'
shells.
* tc/test-locate-httpd (2010-01-02) 1 commit
(merged to 'next' on 2010-01-06 at 9d913e5)
+ t/lib-http.sh: Restructure finding of default httpd location
--------------------------------------------------
[Will merge to 'master' after a bit more cooking in 'next']
* mh/rebase-fixup (2010-01-14) 21 commits
(merged to 'next' on 2010-01-16 at 7ccb228)
+ rebase -i: Retain user-edited commit messages after squash/fixup conflicts
+ t3404: Set up more of the test repo in the "setup" step
+ rebase -i: For fixup commands without squashes, do not start editor
+ rebase -i: Change function make_squash_message into update_squash_message
+ rebase -i: Extract function do_with_author
+ rebase -i: Handle the author script all in one place in do_next
+ rebase -i: Extract a function "commit_message"
+ rebase -i: Simplify commit counting for generated commit messages
+ rebase -i: Improve consistency of commit count in generated commit messages
+ t3404: Test the commit count in commit messages generated by "rebase -i"
+ rebase -i: Introduce a constant AMEND
+ rebase -i: Introduce a constant AUTHOR_SCRIPT
+ rebase -i: Document how temporary files are used
+ rebase -i: Use symbolic constant $MSG consistently
+ rebase -i: Use "test -n" instead of "test ! -z"
+ rebase -i: Inline expression
+ rebase -i: Remove dead code
+ rebase -i: Make the condition for an "if" more transparent
(merged to 'next' on 2010-01-12 at e84eab0)
+ rebase-i: Ignore comments and blank lines in peek_next_command
+ lib-rebase: Allow comments and blank lines to be added to the rebase script
+ lib-rebase: Provide clearer debugging info about what the editor did
+ Add a command "fixup" to rebase --interactive
+ t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
* ns/rebase-auto-squash (2009-12-08) 1 commit
(merged to 'next' on 2010-01-06 at da4e2f5)
+ rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* da/difftool (2010-01-15) 10 commits
(merged to 'next' on 2010-01-16 at 609f0da)
+ difftool: Update copyright notices to list each year separately
+ difftool: Use eval to expand '--extcmd' expressions
+ difftool: Add '-x' and as an alias for '--extcmd'
+ t7800-difftool.sh: Simplify the --extcmd test
(merged to 'next' on 2010-01-10 at 749c870)
+ git-diff.txt: Link to git-difftool
+ difftool: Allow specifying unconfigured commands with --extcmd
+ difftool--helper: Remove use of the GIT_MERGE_TOOL variable
+ difftool--helper: Update copyright and remove distracting comments
(merged to 'next' on 2010-01-06 at e957395)
+ git-difftool: Add '--gui' for selecting a GUI tool
+ t7800-difftool: Set a bogus tool for use by tests
* mm/conflict-advice (2010-01-12) 1 commit
(merged to 'next' on 2010-01-16 at b83be11)
+ Be more user-friendly when refusing to do something because of conflict.
* jc/maint-strbuf-add-fix-doubling (2010-01-12) 1 commit
(merged to 'next' on 2010-01-16 at 5959eee)
+ strbuf_addbuf(): allow passing the same buf to dst and src
* jc/maint-1.6.4-grep-lookahead (2010-01-10) 1 commit
(merged to 'next' on 2010-01-13 at 20f8f4b)
+ grep: optimize built-in grep by skipping lines that do not hit
(this branch is used by jc/grep-lookahead and jc/maint-grep-lookahead.)
Optimize the "line-by-line" internal grep by skiping en masse over lines
that cannot possibly match.
* jc/maint-grep-lookahead (2010-01-12) 0 commits
(this branch uses jc/maint-1.6.4-grep-lookahead; is used by jc/grep-lookahead.)
Early conflict resolution for the above for recent git.
* jc/grep-lookahead (2010-01-15) 4 commits
- grep --no-index: allow use of "git grep" outside a git repository
- grep: prepare to run outside of a work tree
(merged to 'next' on 2010-01-13 at 20f8f4b)
+ grep: rip out pessimization to use fixmatch()
+ grep: rip out support for external grep
(this branch uses jc/maint-1.6.4-grep-lookahead and jc/maint-grep-lookahead.)
* nd/include-termios-for-osol (2010-01-11) 1 commit
(merged to 'next' on 2010-01-16 at 3160c76)
+ Add missing #include to support TIOCGWINSZ on Solaris
* pc/uninteresting-submodule-disappear-upon-switch-branches (2010-01-11) 1 commit
(merged to 'next' on 2010-01-16 at b06ca1a)
+ Remove empty directories when checking out a commit with fewer submodules
Instead of using unlink(2) that will never succeed, use rmdir(2) to remove
an empty directory, knowing that this won't harm a populated directory.
* jl/submodule-diff (2010-01-16) 2 commits
(merged to 'next' on 2010-01-16 at 0a99e3c)
+ Teach diff that modified submodule directory is dirty
+ Show submodules as modified when they contain a dirty work tree
* jc/ls-files-ignored-pathspec (2010-01-08) 4 commits
(merged to 'next' on 2010-01-16 at d36016a)
+ ls-files: fix overeager pathspec optimization
+ read_directory(): further split treat_path()
+ read_directory_recursive(): refactor handling of a single path into a separate function
+ t3001: test ls-files -o ignored/dir
* js/exec-error-report (2010-01-12) 4 commits
(merged to 'next' on 2010-01-16 at 0e28d02)
+ Improve error message when a transport helper was not found
+ start_command: detect execvp failures early
+ run-command: move wait_or_whine earlier
+ start_command: report child process setup errors to the parent's stderr
* jc/fix-tree-walk (2009-09-14) 7 commits
(merged to 'next' on 2010-01-13 at 1c01b87)
+ read-tree --debug-unpack
+ unpack-trees.c: look ahead in the index
+ unpack-trees.c: prepare for looking ahead in the index
+ Aggressive three-way merge: fix D/F case
+ traverse_trees(): handle D/F conflict case sanely
+ more D/F conflict tests
+ tests: move convenience regexp to match object names to test-lib.sh
Resurrected from "Ejected" category. This is fix for a tricky codepath
and testing and improving before it hits 'master' is greatly appreciated.
(I have been using this in my private build for some time).
* jc/cache-unmerge (2009-12-25) 9 commits
(merged to 'next' on 2010-01-13 at 2290c44)
+ rerere forget path: forget recorded resolution
+ rerere: refactor rerere logic to make it independent from I/O
+ rerere: remove silly 1024-byte line limit
+ resolve-undo: teach "update-index --unresolve" to use resolve-undo info
+ resolve-undo: "checkout -m path" uses resolve-undo information
+ resolve-undo: allow plumbing to clear the information
+ resolve-undo: basic tests
+ resolve-undo: record resolved conflicts in a new index extension section
+ builtin-merge.c: use standard active_cache macros
(this branch is used by jc/conflict-mark-len-attr.)
* jc/rerere (2009-12-04) 1 commit
(merged to 'next' on 2010-01-10 at e295b7f)
+ Teach --[no-]rerere-autoupdate option to merge, revert and friends
--------------------------------------------------
[Cooking]
* jc/symbol-static (2010-01-11) 17 commits
- symlinks.c: remove unused functions
- object.c: remove unused functions
- blob.c: remove unused function
- strbuf.c: remove unused function
- sha1_file.c: remove unused function
- mailmap.c: remove unused function
- utf8.c: mark file-local function static
- submodule.c: mark file-local function static
- quote.c: mark file-local function static
- remote-curl.c: mark file-local function static
- read-cache.c: mark file-local functions static
- parse-options.c: mark file-local function static
- entry.c: mark file-local function static
- http.c: mark file-local functions static
- pretty.c: mark file-local function static
- builtin-rev-list.c: mark file-local function static
- bisect.c: mark file-local function static
Mark file-local symbols "static", and remove unused functions. Daniel
suggests to leave some comment for blob.c and I agree in principle, but
I don't think of a good description myself.
* jh/gitweb-cached (2010-01-13) 9 commits
- gitweb: File based caching layer (from git.kernel.org)
- gitweb: Convert output to using indirect file handle
- gitweb: cleanup error message produced by undefined $site_header
- gitweb: add a get function to compliment print_sort_th
- gitweb: add a get function to compliment print_local_time
- gitweb: Makefile improvements
- gitweb: Add option to force version match
- gitweb: change die_error to take "extra" argument for extended die information
- gitweb: Load checking
Replaced with a re-roll. Update to t9500 is probably needed.
* jc/ident (2010-01-08) 3 commits
- ident.c: treat $EMAIL as giving user.email identity explicitly
(merged to 'next' on 2010-01-10 at f1f9ded)
+ ident.c: check explicit identity for name and email separately
+ ident.c: remove unused variables
Opinions on the topmost one?
* jc/branch-d (2009-12-29) 1 commit
(merged to 'next' on 2010-01-10 at 61a14b7)
+ branch -d: base the "already-merged" safety on the branch it merges with
^ permalink raw reply
* Re: [PATCH] builtin-apply.c: Skip filenames without enough components
From: Andreas Gruenbacher @ 2010-01-17 2:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr5ppa2st.fsf@alter.siamese.dyndns.org>
On Sunday 17 January 2010 03:22:10 am Junio C Hamano wrote:
> Tests?
Sure if you think it's worth a regression test ... "git apply -p2" of the
following patch fails with "fatal: git diff header lacks filename information
when removing 2 leading pathname components (line 6)" with the fix, and
creates b/f without:
diff --git a/f b/f
new file mode 100644
index 0000000..6a69f92
--- /dev/null
+++ b/f
@@ -0,0 +1 @@
+f
(Some earlier versions of git failed with "fatal: git apply: bad git-diff -
inconsistent new filename on line 5" in this case.)
Andreas
^ permalink raw reply
* Re: [PATCH] builtin-apply.c: Skip filenames without enough components
From: Junio C Hamano @ 2010-01-17 2:22 UTC (permalink / raw)
To: Andreas Gruenbacher; +Cc: git
In-Reply-To: <201001170305.10793.agruen@suse.de>
Tests?
^ permalink raw reply
* [PATCH] builtin-apply.c: Skip filenames without enough components
From: Andreas Gruenbacher @ 2010-01-17 2:05 UTC (permalink / raw)
To: git
find_name() wrongly returned the whole filename for filenames without
enough leading pathname components (e.g., when applying a patch to a
top-level file with -p2).
Include the -p value used in the error message when no filenames can be
found.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
---
builtin-apply.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 541493e..b99db0b 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -404,6 +404,9 @@ static char *squash_slash(char *name)
{
int i = 0, j = 0;
+ if (!name)
+ return NULL;
+
while (name[i]) {
if ((name[j++] = name[i++]) == '/')
while (name[i] == '/')
@@ -416,7 +419,10 @@ static char *squash_slash(char *name)
static char *find_name(const char *line, char *def, int p_value, int terminate)
{
int len;
- const char *start = line;
+ const char *start = NULL;
+
+ if (p_value == 0)
+ start = line;
if (*line == '"') {
struct strbuf name = STRBUF_INIT;
@@ -1199,7 +1205,8 @@ static int find_header(char *line, unsigned long size, int *hdrsize,
struct patc
continue;
if (!patch->old_name && !patch->new_name) {
if (!patch->def_name)
- die("git diff header lacks filename information (line %d)", linenr);
+ die("git diff header lacks filename information when removing "
+ "%d leading pathname components (line %d)" , p_value, linenr);
patch->old_name = patch->new_name = patch->def_name;
}
patch->is_toplevel_relative = 1;
--
1.6.6.197.g9c4a28
^ permalink raw reply related
* Re: [PATCH v2] Add push --set-upstream
From: Nanako Shiraishi @ 2010-01-16 22:28 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Junio C Hamano, Ilari Liusvaara, git
In-Reply-To: <be6fef0d1001152055j2f178ecifc8e0265446ab75f@mail.gmail.com>
Quoting Tay Ray Chuan <rctay89@gmail.com>
> Hi,
>
> On Sat, Jan 16, 2010 at 12:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> Tay Ray Chuan <rctay89@gmail.com> writes:
>>>
>>>> After all, there's already the config called branch.autosetupmerge and
>>>> branch.autosetuprebase.
>>>
>>> Do you mean Ilari's patch already sets up branch.name.rebase for people
>>> with branch.autosetuprebase true?
>>
>> I checked; the patch uses install_branch_config() so it should get this
>> right automatically.
>
> ok, then ignore my suggestion about --setup-merge and --setup-rebase.
>
> I guess Nanako's query about 'pull --rebase' is settled as well.
I have branch.autosetuprebase so 'git push -u' is good enough for me.
Thanks.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v2 05/14] mingw: support waitpid with pid > 0 and WNOHANG
From: Erik Faye-Lund @ 2010-01-16 21:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001152328.28260.j6t@kdbg.org>
On Fri, Jan 15, 2010 at 11:28 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 15. Januar 2010, Erik Faye-Lund wrote:
>> static inline int waitpid(pid_t pid, int *status, unsigned options)
>> {
>> + if (pid > 0 && options & WNOHANG) {
>> + if (WAIT_OBJECT_0 != WaitForSingleObject((HANDLE)pid, 0))
>> + return 0;
>> + options &= ~WNOHANG;
>> + }
>> +
>> if (options == 0)
>> return _cwait(status, pid, 0);
>> errno = EINVAL;
>
> With this change, and in particular the one in the next patch, this function
> grows too large to be 'static inline'.
>
> -- Hannes
>
Fixed locally.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH v2 07/14] mingw: add kill emulation
From: Erik Faye-Lund @ 2010-01-16 21:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001152331.39199.j6t@kdbg.org>
On Fri, Jan 15, 2010 at 11:31 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 15. Januar 2010, Erik Faye-Lund wrote:
>> +int mingw_kill(pid_t pid, int sig)
>> +{
>> ...
>> + CloseHandle(h);
>> + errno = err_win_to_posix(GetLastError());
>
> Set errno before CloseHandle() to get the correct error.
>
> -- Hannes
>
Thanks for pointing that out. Corrected locally.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH v2 08/14] daemon: use explicit file descriptor
From: Erik Faye-Lund @ 2010-01-16 21:52 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001152336.20662.j6t@kdbg.org>
On Fri, Jan 15, 2010 at 11:36 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 15. Januar 2010, Erik Faye-Lund wrote:
>> This patch adds support to specify an explicit file
>> descriotor for communication with the client, instead
>> of using stdin/stdout.
>>
>> This will be useful for the Windows port, because it
>> will use threads instead of fork() to serve multiple
>> clients, making it impossible to reuse stdin/stdout.
>
> This statement is a bit outdated.
>
> -- Hannes
>
Heh, yeah. I apparently missed that this patch isn't needed at all any more.
Thanks for noticing something was off :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH v4] Add push --set-upstream
From: Ilari Liusvaara @ 2010-01-16 21:45 UTC (permalink / raw)
To: git
Frequent complaint is lack of easy way to set up upstream (tracking)
references for git pull to work as part of push command. So add switch
--set-upstream (-u) to do just that.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
Documentation/git-push.txt | 9 +++++-
builtin-push.c | 2 +
t/t5523-push-upstream.sh | 69 ++++++++++++++++++++++++++++++++++++++++++++
transport.c | 56 +++++++++++++++++++++++++++++++++++
transport.h | 1 +
5 files changed, 136 insertions(+), 1 deletions(-)
create mode 100755 t/t5523-push-upstream.sh
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index e3eb1e8..2a5394b 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
+ [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
[<repository> <refspec>...]
DESCRIPTION
@@ -122,6 +122,13 @@ nor in any Push line of the corresponding remotes file---see below).
the name "origin" is used. For this latter case, this option
can be used to override the name "origin". In other words,
the difference between these two commands
+
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference, used by argument-less
+ linkgit:git-pull[1] and other commands. For more information,
+ see 'branch.<name>.merge' in linkgit:git-config[1].
+
--------------------------
git push public #1
diff --git a/builtin-push.c b/builtin-push.c
index 28a26e7..5df6608 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -218,6 +218,8 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
+ OPT_BIT('u', "set-upstream", &flags, "set upstream for git pull/status",
+ TRANSPORT_PUSH_SET_UPSTREAM),
OPT_END()
};
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
new file mode 100755
index 0000000..00da707
--- /dev/null
+++ b/t/t5523-push-upstream.sh
@@ -0,0 +1,69 @@
+#!/bin/sh
+
+test_description='push with --set-upstream'
+. ./test-lib.sh
+
+test_expect_success 'setup bare parent' '
+ git init --bare parent &&
+ git remote add upstream parent
+'
+
+test_expect_success 'setup local commit' '
+ echo content >file &&
+ git add file &&
+ git commit -m one
+'
+
+check_config() {
+ (echo $2; echo $3) >expect.$1
+ (git config branch.$1.remote
+ git config branch.$1.merge) >actual.$1
+ test_cmp expect.$1 actual.$1
+}
+
+test_expect_success 'push -u master:master' '
+ git push -u upstream master:master &&
+ check_config master upstream refs/heads/master
+'
+
+test_expect_success 'push -u master:other' '
+ git push -u upstream master:other &&
+ check_config master upstream refs/heads/other
+'
+
+test_expect_success 'push -u --dry-run master:otherX' '
+ git push -u --dry-run upstream master:otherX &&
+ check_config master upstream refs/heads/other
+'
+
+test_expect_success 'push -u master2:master2' '
+ git branch master2 &&
+ git push -u upstream master2:master2 &&
+ check_config master2 upstream refs/heads/master2
+'
+
+test_expect_success 'push -u master2:other2' '
+ git push -u upstream master2:other2 &&
+ check_config master2 upstream refs/heads/other2
+'
+
+test_expect_success 'push -u :master2' '
+ git push -u upstream :master2 &&
+ check_config master2 upstream refs/heads/other2
+'
+
+test_expect_success 'push -u --all' '
+ git branch all1 &&
+ git branch all2 &&
+ git push -u --all &&
+ check_config all1 upstream refs/heads/all1 &&
+ check_config all2 upstream refs/heads/all2
+'
+
+test_expect_success 'push -u HEAD' '
+ git checkout -b headbranch &&
+ git push -u upstream HEAD &&
+ check_config headbranch upstream refs/heads/headbranch
+'
+
+test_done
diff --git a/transport.c b/transport.c
index b5332c0..8cc287d 100644
--- a/transport.c
+++ b/transport.c
@@ -8,6 +8,7 @@
#include "bundle.h"
#include "dir.h"
#include "refs.h"
+#include "branch.h"
/* rsync support */
@@ -135,6 +136,53 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
}
}
+static void set_upstreams(struct transport *transport, struct ref *refs,
+ int pretend)
+{
+ struct ref *ref;
+ for (ref = refs; ref; ref = ref->next) {
+ const char *localname;
+ const char *tmp;
+ const char *remotename;
+ unsigned char sha[20];
+ int flag = 0;
+ /*
+ * Check suitability for tracking. Must be successful /
+ * already up-to-date ref create/modify (not delete).
+ */
+ if (ref->status != REF_STATUS_OK &&
+ ref->status != REF_STATUS_UPTODATE)
+ continue;
+ if (!ref->peer_ref)
+ continue;
+ if (!ref->new_sha1 || is_null_sha1(ref->new_sha1))
+ continue;
+
+ /* Follow symbolic refs (mainly for HEAD). */
+ localname = ref->peer_ref->name;
+ remotename = ref->name;
+ tmp = resolve_ref(localname, sha, 1, &flag);
+ if (tmp && flag & REF_ISSYMREF &&
+ !prefixcmp(tmp, "refs/heads/"))
+ localname = tmp;
+
+ /* Both source and destination must be local branches. */
+ if (!localname || prefixcmp(localname, "refs/heads/"))
+ continue;
+ if (!remotename || prefixcmp(remotename, "refs/heads/"))
+ continue;
+
+ if (!pretend)
+ install_branch_config(BRANCH_CONFIG_VERBOSE,
+ localname + 11, transport->remote->name,
+ remotename);
+ else
+ printf("Would set upstream of '%s' to '%s' of '%s'\n",
+ localname + 11, remotename + 11,
+ transport->remote->name);
+ }
+}
+
static const char *rsync_url(const char *url)
{
return prefixcmp(url, "rsync://") ? skip_prefix(url, "rsync:") : url;
@@ -974,6 +1022,10 @@ int transport_push(struct transport *transport,
verify_remote_names(refspec_nr, refspec);
if (transport->push) {
+ /* Maybe FIXME. But no important transport uses this case. */
+ if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+ die("This transport does not support using --set-upstream");
+
return transport->push(transport, refspec_nr, refspec, flags);
} else if (transport->push_refs) {
struct ref *remote_refs =
@@ -983,6 +1035,7 @@ int transport_push(struct transport *transport,
int verbose = flags & TRANSPORT_PUSH_VERBOSE;
int quiet = flags & TRANSPORT_PUSH_QUIET;
int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
+ int pretend = flags & TRANSPORT_PUSH_DRY_RUN;
int ret;
if (flags & TRANSPORT_PUSH_ALL)
@@ -1002,6 +1055,9 @@ int transport_push(struct transport *transport,
verbose | porcelain, porcelain,
nonfastforward);
+ if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+ set_upstreams(transport, remote_refs, pretend);
+
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
for (ref = remote_refs; ref; ref = ref->next)
diff --git a/transport.h b/transport.h
index 97ba251..c4314dd 100644
--- a/transport.h
+++ b/transport.h
@@ -91,6 +91,7 @@ struct transport {
#define TRANSPORT_PUSH_VERBOSE 16
#define TRANSPORT_PUSH_PORCELAIN 32
#define TRANSPORT_PUSH_QUIET 64
+#define TRANSPORT_PUSH_SET_UPSTREAM 128
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
--
1.6.6.199.gff4b0
^ permalink raw reply related
* Re: [PATCH v2 13/14] daemon: use select() instead of poll()
From: Erik Faye-Lund @ 2010-01-16 21:31 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git
In-Reply-To: <201001161336.20703.j6t@kdbg.org>
On Sat, Jan 16, 2010 at 1:36 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Samstag, 16. Januar 2010, Erik Faye-Lund wrote:
>> ...but __WSAFDIsSet() seems to be every bit as official on Windows as
>> FD_ISSET() (documented in msdn, without any notes not to use it), so I
>> still don't really see the point.
>
> I didn't know nor check whether it is documented, but assumed from the '__'
> that it must be internal. Being documented makes a big difference. I'm fine
> with either solution.
>
OK, in that case, I'll leave it as it is. The current code is slightly
more tested (I've been using it for some weeks), and I'm slightly lazy
;)
But I'll update FD_SET...
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Jakub Narebski @ 2010-01-16 21:27 UTC (permalink / raw)
To: Paul Richards; +Cc: git
In-Reply-To: <a1138db31001161312i2c032c38tcc0fb162c61fbb35@mail.gmail.com>
Dnia sobota 16. stycznia 2010 22:12, Paul Richards napisał:
> 2010/1/16 Jakub Narebski <jnareb@gmail.com>:
>> Paul Richards <paul.richards@gmail.com> writes:
>>> I am in the process of migrating from Subversion to Git. One thing I
>>> am unsure of is how to stamp the 'version' or 'commit id' into a file
>>> as part of a build process.
>> Take a look how for example git project and Linux kernel use "git describe"
>> in GIT-VERSION-GEN script, and how they use GIT-VERSION-GEN script in the
>> Makefile.
>
> Thanks, it appears though that "git describe" does not work in Cygwin git. :(
If you got something like
$ git describe
fatal: cannot describe 'a27cb622b30f18cb8510b7b3856d4029e617d95b'
it means that you don't have any tags in your history. You should tag your
releases (released versions) using annotated tags.
Anyway you have
$ git describe --always
a27cb62
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Shawn O. Pearce @ 2010-01-16 21:26 UTC (permalink / raw)
To: Paul Richards; +Cc: git, Jakub Narebski
In-Reply-To: <a1138db31001161312i2c032c38tcc0fb162c61fbb35@mail.gmail.com>
Paul Richards <paul.richards@gmail.com> wrote:
> > Take a look how for example git project and Linux kernel use "git describe"
> > in GIT-VERSION-GEN script, and how they use GIT-VERSION-GEN script in the
> > Makefile.
>
> Thanks, it appears though that "git describe" does not work in Cygwin git. :(
That's a serious bug. git describe should work fine on any system
Git itself runs on; its written in pure C and with the exception
of the --contains flag, doesn't rely on any external programs.
--
Shawn.
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Paul Richards @ 2010-01-16 21:12 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski
In-Reply-To: <m3d419desd.fsf@localhost.localdomain>
2010/1/16 Jakub Narebski <jnareb@gmail.com>:
> Paul Richards <paul.richards@gmail.com> writes:
>
>> Hi,
>> I am in the process of migrating from Subversion to Git. One thing I
>> am unsure of is how to stamp the 'version' or 'commit id' into a file
>> as part of a build process.
>>
>> With subversion I used the SubWCRev tool from TortoiseSVN
>> (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html).
>>
>> With Git I imagine that I'd like to put a copy of the current commit
>> id (either the full hash or a truncated version of that) into a file
>> which then gets included into the program source code in some way.
>>
>> Is there a recommended way of doing this with git? Perhaps with
>> something similar to SubWCRev?
>>
>> Currently I am thinking about using "git log", and grepping the output
>> in some way so that I just get the hash.
>
> Not "git log".
>
> Take a look how for example git project and Linux kernel use "git describe"
> in GIT-VERSION-GEN script, and how they use GIT-VERSION-GEN script in the
> Makefile.
>
Thanks, it appears though that "git describe" does not work in Cygwin git. :(
--
Paul Richards
^ permalink raw reply
* Re: Integration-Manager Workflow
From: Adrián Ribao Martínez @ 2010-01-16 19:47 UTC (permalink / raw)
To: Michael Poole; +Cc: git
In-Reply-To: <87r5ppx42f.fsf@troilus.org>
[-- Attachment #1: Type: Text/Plain, Size: 1965 bytes --]
> Adrián Ribao Martínez writes:
>
> > What happens if they accidentally work in the develop branch instead of creating a new one? What should we do?
> > I think I should never fetch from teamx.myserver.net to avoid this problem and instead track the branch like in step 2. Is this correct?
>
> It is simpler than that.
>
> If you just use "git remote add teamx teamx.myserver.net:/...." (rather
> than cloning your integration repository from one of those
> repositories), it will leave all your local branches alone -- any
> changes to teamx.myserver.net's "develop" branch will only show up in
> the teamx/develop tracking branch.
I think this is a stupid question but, how do I bring the feature1 branch from teamx to my local repository?
>
> The reason is that a fetch or pull only merges into your develop branch
> if your branch.develop.merge git-config entry specifies an upstream
> branch -- more detail can be found in the git-config man page under
> branch.<name>.remote and branch.<name>.merge.
>
> Those entries are set up when you clone from a repository, and through
> some other commands, but if teamx clones from the integration server,
> they can only mess up their own develop branch. If/when you push into
> teamx's repository from yours, you can forcibly overwrite any of those
> accidental changes. (Normally, though, the push would only do a
> fast-forward merge -- so if teamx made such a mistake, the merge will
> fail until you address the mismatch.)
I'm not sure if I understand.
1. I bring the feature1 to my local repository.
2. Check if everything is ok
3. Merge or rebase the branch into develop
4. Push the develop changes into the in central repository
5. Push and force the develop changes into the teamx server
6. The developers pull their local repositories from teamx server
Is this correct? What are the commands for all those actions?
>
> Michael Poole
>
Thank you.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Jakub Narebski @ 2010-01-16 19:35 UTC (permalink / raw)
To: Paul Richards; +Cc: git
In-Reply-To: <a1138db31001161050i73eade1bif968ca1256dcef2c@mail.gmail.com>
Paul Richards <paul.richards@gmail.com> writes:
> Hi,
> I am in the process of migrating from Subversion to Git. One thing I
> am unsure of is how to stamp the 'version' or 'commit id' into a file
> as part of a build process.
>
> With subversion I used the SubWCRev tool from TortoiseSVN
> (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html).
>
> With Git I imagine that I'd like to put a copy of the current commit
> id (either the full hash or a truncated version of that) into a file
> which then gets included into the program source code in some way.
>
> Is there a recommended way of doing this with git? Perhaps with
> something similar to SubWCRev?
>
> Currently I am thinking about using "git log", and grepping the output
> in some way so that I just get the hash.
Not "git log".
Take a look how for example git project and Linux kernel use "git describe"
in GIT-VERSION-GEN script, and how they use GIT-VERSION-GEN script in the
Makefile.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Sverre Rabbelier @ 2010-01-16 19:29 UTC (permalink / raw)
To: kusmabite; +Cc: Paul Richards, git
In-Reply-To: <40aa078e1001161122k48f55807y3f01fa0d38e5cc93@mail.gmail.com>
Heya,
On Sat, Jan 16, 2010 at 20:22, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> Since he's looking for a replacement for SubWCRev (as opposed to
> svn:keywords); not really.
I misunderstood then, since he mentioned 'git log' and you mentioned
'git rev-parse HEAD', and I do not know what SubWCRev does.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Erik Faye-Lund @ 2010-01-16 19:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Paul Richards, git
In-Reply-To: <fabb9a1e1001161117t6d572024yc5598be1b32ffcde@mail.gmail.com>
On Sat, Jan 16, 2010 at 8:17 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Sat, Jan 16, 2010 at 20:14, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>> I think you are looking for "git rev-parse HEAD". This outputs the
>> hash of HEAD as a single line on stdout. Or even better, you can use
>> the "git describe"-tool, which gives a nice and short description of
>> the commit relative to the most recent commit.
>
> It would be better to have a look at gitattributes [0] instead.
>
Since he's looking for a replacement for SubWCRev (as opposed to
svn:keywords); not really.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Sverre Rabbelier @ 2010-01-16 19:17 UTC (permalink / raw)
To: kusmabite; +Cc: Paul Richards, git
In-Reply-To: <40aa078e1001161114w5a65bebbhaf43317634899925@mail.gmail.com>
Heya,
On Sat, Jan 16, 2010 at 20:14, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> I think you are looking for "git rev-parse HEAD". This outputs the
> hash of HEAD as a single line on stdout. Or even better, you can use
> the "git describe"-tool, which gives a nice and short description of
> the commit relative to the most recent commit.
It would be better to have a look at gitattributes [0] instead.
[0] http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html#_tt_ident_tt
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Erik Faye-Lund @ 2010-01-16 19:15 UTC (permalink / raw)
To: Paul Richards; +Cc: git
In-Reply-To: <40aa078e1001161114w5a65bebbhaf43317634899925@mail.gmail.com>
On Sat, Jan 16, 2010 at 8:14 PM, Erik Faye-Lund
<kusmabite@googlemail.com> wrote:
> the "git describe"-tool, which gives a nice and short description of
> the commit relative to the most recent commit.
>
...by "most recent commit", I mean "most recent tag". Sorry about that.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Stamp Git commit id into file during build process
From: Erik Faye-Lund @ 2010-01-16 19:14 UTC (permalink / raw)
To: Paul Richards; +Cc: git
In-Reply-To: <a1138db31001161050i73eade1bif968ca1256dcef2c@mail.gmail.com>
On Sat, Jan 16, 2010 at 7:50 PM, Paul Richards <paul.richards@gmail.com> wrote:
> Hi,
> I am in the process of migrating from Subversion to Git. One thing I
> am unsure of is how to stamp the 'version' or 'commit id' into a file
> as part of a build process.
>
> With subversion I used the SubWCRev tool from TortoiseSVN
> (http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html).
>
> With Git I imagine that I'd like to put a copy of the current commit
> id (either the full hash or a truncated version of that) into a file
> which then gets included into the program source code in some way.
>
> Is there a recommended way of doing this with git? Perhaps with
> something similar to SubWCRev?
>
> Currently I am thinking about using "git log", and grepping the output
> in some way so that I just get the hash.
>
I think you are looking for "git rev-parse HEAD". This outputs the
hash of HEAD as a single line on stdout. Or even better, you can use
the "git describe"-tool, which gives a nice and short description of
the commit relative to the most recent commit.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Integration-Manager Workflow
From: Michael Poole @ 2010-01-16 19:06 UTC (permalink / raw)
To: Adrián Ribao Martínez; +Cc: git
In-Reply-To: <201001161849.32211.aribao@gmail.com>
Adrián Ribao Martínez writes:
> What happens if they accidentally work in the develop branch instead of creating a new one? What should we do?
> I think I should never fetch from teamx.myserver.net to avoid this problem and instead track the branch like in step 2. Is this correct?
It is simpler than that.
If you just use "git remote add teamx teamx.myserver.net:/...." (rather
than cloning your integration repository from one of those
repositories), it will leave all your local branches alone -- any
changes to teamx.myserver.net's "develop" branch will only show up in
the teamx/develop tracking branch.
The reason is that a fetch or pull only merges into your develop branch
if your branch.develop.merge git-config entry specifies an upstream
branch -- more detail can be found in the git-config man page under
branch.<name>.remote and branch.<name>.merge.
Those entries are set up when you clone from a repository, and through
some other commands, but if teamx clones from the integration server,
they can only mess up their own develop branch. If/when you push into
teamx's repository from yours, you can forcibly overwrite any of those
accidental changes. (Normally, though, the push would only do a
fast-forward merge -- so if teamx made such a mistake, the merge will
fail until you address the mismatch.)
Michael Poole
^ permalink raw reply
* Stamp Git commit id into file during build process
From: Paul Richards @ 2010-01-16 18:50 UTC (permalink / raw)
To: git
Hi,
I am in the process of migrating from Subversion to Git. One thing I
am unsure of is how to stamp the 'version' or 'commit id' into a file
as part of a build process.
With subversion I used the SubWCRev tool from TortoiseSVN
(http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html).
With Git I imagine that I'd like to put a copy of the current commit
id (either the full hash or a truncated version of that) into a file
which then gets included into the program source code in some way.
Is there a recommended way of doing this with git? Perhaps with
something similar to SubWCRev?
Currently I am thinking about using "git log", and grepping the output
in some way so that I just get the hash.
Thanks in advance,
--
Paul Richards
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 18:43 UTC (permalink / raw)
To: Ilari Liusvaara
Cc: Junio C Hamano, Jeff King, Nanako Shiraishi, Johannes Schindelin,
Rudolf Polzer, Miles Bader, Martin Langhoff, git
In-Reply-To: <20100116134656.GA4504@Knoppix>
Hi,
yet again, this patch has gone through another iteration, so I'm
adding people from the 'git push --track' thread here.
--
Cheers,
Ray Chuan
On Sat, Jan 16, 2010 at 9:46 PM, Ilari Liusvaara
<ilari.liusvaara@elisanet.fi> wrote:
> On Sat, Jan 16, 2010 at 08:35:57PM +0800, Tay Ray Chuan wrote:
>> Hi,
>>
>> On Sat, 16 Jan 2010 11:23:47 +0200
>> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
>> > + OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
>>
>> This line exceeds 80 characters.
>
> Broken into two (without breaking the message), it is still over 80.
>
>> Also, I think you should follow the case-style of the other option
>> descriptions and s/Set(?= upstream)/set/.
>
> Fixed.
>
>> > [snip]
>> > +static void set_upstreams(struct transport *trans, struct ref *refs,
>>
>> I would prefer if you could follow the naming convention and say
>> "transport" instead of truncating to "trans".
>
> Fixed.
>
>> > + struct ref *i;
>> > + for (i = refs; i; i = i->next) {
>>
>> In most places, "ref" instead of "i" is used; ie.
>
> Fixed.
>
>> > + * alreay up-to-date ref create/modify (not delete).
>>
>> s/alreay/already/.
>
> Fixed.
>
>> > + /* Chase symbolic refs (mainly for HEAD). */
>>
>> Did you mean "Change" here?
>
> No. Changed to 'Follow'.
>
>> Regarding the checking of ref->status here:
>>
>> Is it possible to delegate this to push_had_errors(remote_refs)
>> instead? We skip setting up upstream tracking when there are errors
>> from pushing, so we don't have to check ref->status anymore.
>
> No. As documetnation says, the update or no update is done on per-branch
> basis.
>
> <snip patch>
>
>> (As a side note, if you apply this on top of 'tr/http-push-ref-status'
>> in 'pu', the result of push_had_errors() is saved in a variable
>> ('err'), so you could just use it and not have to call push_had_errors
>> () again.)
>
> See above.
>
> I'll sit on v4 for some more time to wait for more comments.
>
> -Ilari
>
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Tay Ray Chuan @ 2010-01-16 18:39 UTC (permalink / raw)
To: Jeff King; +Cc: Ilari Liusvaara, git
In-Reply-To: <20100116182829.GA27474@sigill.intra.peff.net>
Hi,
On Sun, Jan 17, 2010 at 2:28 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Jan 17, 2010 at 12:13:20AM +0800, Tay Ray Chuan wrote:
>
>> On Sat, Jan 16, 2010 at 11:56 PM, Ilari Liusvaara
>> <ilari.liusvaara@elisanet.fi> wrote:
>> > Hmm... In what conditions ref->status is 'none' after push operation
>> > has completed?
>>
>> when a match between a local and remote ref is not found.
>>
>> For example, the local ref 'master' will match the remote ref
>> 'master', but not 'retsam' ('master' spelled in reverse).
>
> How would it make any sense to set up a tracking branch, then? Not only
> is it not desired (if I said "git push -u foo:bar", I don't expect it to
> do _anything_ with some other local branch besides foo), but it wouldn't
> work, since the peer_ref pointer would be NULL.
Noted.
Ilari, please ignore my thought on 'none' then.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: [PATCH v3] Add push --set-upstream
From: Jeff King @ 2010-01-16 18:28 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Ilari Liusvaara, git
In-Reply-To: <be6fef0d1001160813o674ed93dn33843813be6f45be@mail.gmail.com>
On Sun, Jan 17, 2010 at 12:13:20AM +0800, Tay Ray Chuan wrote:
> On Sat, Jan 16, 2010 at 11:56 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > Hmm... In what conditions ref->status is 'none' after push operation
> > has completed?
>
> when a match between a local and remote ref is not found.
>
> For example, the local ref 'master' will match the remote ref
> 'master', but not 'retsam' ('master' spelled in reverse).
How would it make any sense to set up a tracking branch, then? Not only
is it not desired (if I said "git push -u foo:bar", I don't expect it to
do _anything_ with some other local branch besides foo), but it wouldn't
work, since the peer_ref pointer would be NULL.
-Peff
^ 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