* Re: setting up tracking on push
From: Nanako Shiraishi @ 2009-03-11 10:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jay Soffian, Marc Branchaud, Miles Bader, git
In-Reply-To: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>:
> The only use case I've heard in this thread and nearby is where you are
> the one who started the history of the branch, and pushed it into a public
> repository as a new branch, making the result _the_ most authoritative
> one. After that, everybody else will be able to have a local branch that
> tracks the authoritative one with "branch --track frotz origin/frotz", and
> you will be the only one left unable to do so because you already have
> that frotz branch.
>
> And for that use case, I find it sensible if we had a way to easily say
> "This branch hasn't been tracking anything so far (because it is the
> originator of the history), but now it will give up its authority and
> start tracking the one it is pushing into", and it would make sense to
> somehow link that to the invocation of "git push".
>
> Side note. I would also accept "It is only one person in the world,
> who can edit .git/config and be done with it; why bother complicate
> the UI for other people" as a valid argument against it, though ;-).
>
> In that "my private branch gave autority to the branch at my public
> repository" case, it is of course easy to re-clone (or "branch -m" away
> and then re-fetch) like everybody else, but then you would lose the reflog
> from the time before the branch went public, so it is not a solution but a
> poor workaround.
I'm sorry, but I don't understand why you want to keep the entries in the reflog that were made before you pushed your branch to make it public in this scenario.
Especially because you are relinquishing the authority to the public repository by wishing to be able to "track" it, you can't rewind the branch beyond the point you initially pushed out any more. At that point, wouldn't it make more sense to drop the old reflog data and pretend as if the branch were fetched from the branch from your public repository it now follows, just like everybody else does?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: What's cooking in git.git (Mar 2009, #03; Wed, 11)
From: Felipe Contreras @ 2009-03-11 9:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vvdqg5s17.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 11:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> ----------------------------------------------------------------
> [Actively cooking]
>
> * fc/parseopt-config (Sat Mar 7 12:14:05 2009 -0500) 9 commits
> + config: set help text for --bool-or-int
> + git config: don't allow --get-color* and variable type
> + git config: don't allow extra arguments for -e or -l.
> + git config: don't allow multiple variable types
> + git config: don't allow multiple config file locations
> + git config: reorganize to use parseopt
> + git config: reorganize get_color*
> + git config: trivial rename in preparation for parseopt
> + git_config(): not having a per-repo config file is not an error
Can you answer my last email regarding this? You didn't like my last
patch and explained me how the config --get-color* stuff works, and
now that I understand I think the patch still makes sense.
--
Felipe Contreras
^ permalink raw reply
* Re: Generalised bisection
From: John Tapsell @ 2009-03-11 9:35 UTC (permalink / raw)
To: Ealdwulf Wuffinga; +Cc: Christian Couder, Git List, Ingo Molnar
In-Reply-To: <efe2b6d70903110159h78de744yc141effaf5aa0821@mail.gmail.com>
2009/3/11 Ealdwulf Wuffinga <ealdwulf@googlemail.com>:
> On Tue, Mar 10, 2009 at 7:08 AM, Christian Couder
> <chriscool@tuxfamily.org> wrote:
>
>> I will try to have a look at the end of this week.
>> But do you want it to be integrated with Git or do you want it to be an
>> independant project that works with many different version control system?
>
> Hmm. Whatever works, I guess. On the one hand the code does seem
> naturally generic. On the other hand, it's good if users don't
> have to separately obtain an extra package to use it. Supposing that
> the algorithm proves useful, would the git project be okay with an
> extra dependency, or would you want to integrate it? Right now it's in
> python, which I understand is an obstacle to integration.
There used to be a dependency on python. git-merge-recursive for
example, before it was converted to C.
mpmath might be the more annoying dependency - what functions do you
use from it? Could they trivially be reimplemented?
John Tapsell
^ permalink raw reply
* What's cooking in git.git (Mar 2009, #03; Wed, 11)
From: Junio C Hamano @ 2009-03-11 9:26 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Tonight's 'pu' does not pass its self-test and it is expected; I won't be
fixing it and I'm going to bed now.
----------------------------------------------------------------
[New Topics]
* db/maint-missing-origin (Wed Mar 11 01:47:20 2009 -0400) 1 commit
- Give error when no remote is configured
* js/sideband-stderr (Tue Mar 10 22:58:09 2009 +0100) 2 commits
- winansi: support ESC [ K (erase in line)
- recv_sideband: Bands #2 and #3 always go to stderr
* js/rsync-local (Mon Mar 9 19:44:55 2009 +0100) 1 commit
- rsync transport: allow local paths, and fix tests
* rs/color-grep (Sun Mar 8 18:22:44 2009 -0700) 6 commits
+ grep: cast printf %.*s "precision" argument explicitly to int
+ grep: add support for coloring with external greps
+ grep: color patterns in output
+ grep: add pmatch and eflags arguments to match_one_pattern()
+ grep: remove grep_opt argument from match_expr_eval()
+ grep: micro-optimize hit collection for AND nodes
* db/refspec-wildcard-in-the-middle (Sat Mar 7 01:11:39 2009 -0500) 5 commits
+ Support '*' in the middle of a refspec
+ Keep '*' in pattern refspecs
+ Use the matching function to generate the match results
+ Use a single function to match names against patterns
+ Make clone parse the default refspec with the normal code
* db/push-cleanup (Sun Mar 8 21:06:07 2009 -0400) 2 commits
- Move push matching and reporting logic into transport.c
- Use a common function to get the pretty name of refs
* xx/db-refspec-vs-js-remote (Sun Mar 8 00:12:33 2009 -0800) 1 commit
+ Adjust js/remote-improvements and db/refspec-wildcard-in-the-
middle
* fg/push-default (Mon Mar 9 23:35:51 2009 +0100) 7 commits
- git push: Remove warning for "git push" default change
- git push: Change default for "git push" to nothing.
- git push: Document that "nothing" is the future push default
- git push: Display warning on unconfigured default push
- git push: New options --matching and --current
- New config option push.default
- remote: Make "-" an alias for the current remote
With the topmost three patches, tonight's 'pu' does not pass the self test
as expected. I am not sure there is a wide support for changing the
default, either.
* kg/http-auth (Mon Mar 9 23:34:25 2009 -0700) 3 commits
- http authentication via prompts
- http_init(): Fix config file parsing
- http.c: style cleanups
This only deals with the fetch side.
* jc/log-tz (Tue Mar 3 00:45:37 2009 -0800) 1 commit
- Allow --date=local --date=other-format to work as expected
The one I posted had a few corner-case bugs that was caught with the test
suite; this one has them fixed.
----------------------------------------------------------------
[Graduated to "master"]
* jk/sane-relative-time (Tue Feb 24 00:42:16 2009 -0500) 1 commit
+ never fallback relative times to absolute
* js/send-email (Mon Mar 2 23:52:18 2009 -0500) 5 commits
+ send-email: add --confirm option and configuration setting
+ send-email: don't create temporary compose file until it is needed
+ send-email: --suppress-cc improvements
+ send-email: handle multiple Cc addresses when reading mbox message
+ send-email: allow send-email to run outside a repo
* sg/rerere-cleanup (Sat Feb 14 23:21:04 2009 +0100) 1 commit
+ rerere: remove duplicated functions
* jc/add-p-unquote (Mon Feb 16 22:43:43 2009 -0800) 1 commit
+ git-add -i/-p: learn to unwrap C-quoted paths
* jw/imap-preformatted-html (Thu Feb 12 08:58:12 2009 -0600) 1 commit
+ imap.preformattedHTML to tell Thunderbird to send non-flowed text
* jw/format-patch-attach (Thu Feb 12 09:51:55 2009 -0600) 1 commit
+ Enable setting attach as the default in .gitconfig for git-format-
patch.
* sr/force-rebase (Fri Feb 13 23:48:01 2009 +0100) 1 commit
+ Teach rebase to rebase even if upstream is up to date
* fg/exclude-bq (Tue Feb 10 15:20:17 2009 +0100) 1 commit
+ Support "\" in non-wildcard exclusion entries
* dm/add-i-edit-abort (Thu Feb 12 00:19:41 2009 -0500) 1 commit
+ add -i: revisit hunk on editor failure
* tp/completion (Sat Feb 21 15:48:43 2009 +0100) 6 commits
+ Fixup: Add bare repository indicator for __git_ps1
+ Add bare repository indicator for __git_ps1
+ completion: More fixes to prevent unbound variable errors
+ completion: Better __git_ps1 support when not in working directory
+ completion: Use consistent if [...] convention, not "test"
+ completion: For consistency, change "git rev-parse" to __gitdir
calls
* js/branch-symref (Wed Feb 18 22:34:44 2009 -0500) 4 commits
+ add basic branch display tests
+ branch: clean up repeated strlen
+ Avoid segfault with 'git branch' when the HEAD is detached
+ builtin-branch: improve output when displaying remote branches
* al/ansi-color (Fri Feb 13 22:53:41 2009 +0100) 2 commits
+ builtin-branch.c: Rename branch category color names
+ Clean up use of ANSI color sequences
* js/valgrind (Thu Feb 5 22:03:00 2009 +0100) 9 commits
+ valgrind: do not require valgrind 3.4.0 or newer
+ test-lib: avoid assuming that templates/ are in the GIT_EXEC_PATH
+ Tests: let --valgrind imply --verbose and --tee
+ Add a script to coalesce the valgrind outputs
+ t/Makefile: provide a 'valgrind' target
+ test-lib.sh: optionally output to test-results/$TEST.out, too
+ Valgrind support: check for more than just programming errors
+ valgrind: ignore ldso and more libz errors
+ Add valgrind support in test scripts
* fc/config-editor (Sat Feb 21 02:48:54 2009 +0200) 3 commits
+ git config: trivial cleanup for editor action
+ git config: codestyle cleanups
+ config: Add new option to open an editor.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
* ns/pretty-format (Tue Feb 24 15:33:29 2009 +0200) 5 commits
+ bash completion: add --format= and --oneline options for "git log"
+ Add tests for git log --pretty, --format and --oneline.
+ Add --oneline that is a synonym to "--pretty=oneline --abbrev-
commit"
+ Give short-hands to --pretty=tformat:%formatstring
+ Add --format that is a synonym to --pretty
* en/maint-hash-object (Sat Feb 28 12:56:49 2009 -0700) 1 commit
+ Ensure proper setup of git_dir for git-hash-object
----------------------------------------------------------------
[Will merge to 'master' soon]
* mg/maint-submodule-normalize-path (Tue Mar 3 16:08:21 2009 +0100) 2 commits
+ git submodule: Fix adding of submodules at paths with ./, .. and
//
+ git submodule: Add test cases for git submodule add
* rs/memmem (Tue Mar 3 00:19:30 2009 +0100) 2 commits
+ optimize compat/ memmem()
+ diffcore-pickaxe: use memmem()
* tv/rebase-stat (Sun Mar 1 22:28:28 2009 +0100) 2 commits
+ git-pull: Allow --stat and --no-stat to be used with --rebase
+ git-rebase: Add --stat and --no-stat for producing diffstat on
rebase
* jk/clone-post-checkout (Tue Mar 3 00:37:51 2009 -0500) 1 commit
+ clone: run post-checkout hook when checking out
* jc/maint-1.6.0-keep-pack (Sat Feb 28 00:37:19 2009 -0800) 6 commits
+ is_kept_pack(): final clean-up
+ Simplify is_kept_pack()
+ Consolidate ignore_packed logic more
+ has_sha1_kept_pack(): take "struct rev_info"
+ has_sha1_pack(): refactor "pretend these packs do not exist"
interface
+ git-repack: resist stray environment variable
This is in response to Linus's "Really slow 'git gc'" ($gmane/110743)
* el/blame-date (Fri Feb 20 14:51:11 2009 -0800) 1 commit
+ Make git blame's date output format configurable, like git log
* tr/gcov (Thu Feb 19 12:13:42 2009 +0100) 8 commits
+ Test git-patch-id
+ Test rev-list --parents/--children
+ Test log --decorate
+ Test fsck a bit harder
+ Test log --graph
+ Test diff --dirstat functionality
+ Test that diff can read from stdin
+ Support coverage testing with GCC/gcov
* tr/format-patch-thread (Thu Feb 19 22:26:33 2009 +0100) 4 commits
+ format-patch: support deep threading
+ format-patch: thread as reply to cover letter even with in-reply-
to
+ format-patch: track several references
+ format-patch: threading test reactivation
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 1 commit
- archive.c: add support for --submodules[=(all|checkedout)]
Discussion stalled on the submodule selection criteria.
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user.
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I think the code is much cleaner than the first round, but I am not
convinced it is doing the right thing in the connectivity traverser.
Independent review sorely needed.
----------------------------------------------------------------
[Discarded]
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
. gitweb: Optional grouping of projects by category
. gitweb: Split git_project_list_body in two functions
. gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien seems to have stalled, but
Jakub seems to be taking this over.
* jc/push-to-create (Mon Mar 2 22:36:16 2009 -0800) 1 commit
. Push to create
This was a failed weatherbaloon patch to allow creation of a new
repository from the remote side.
----------------------------------------------------------------
[Actively cooking]
* hv/cvsimport-tests (Mon Mar 2 18:59:36 2009 +0100) 1 commit
- cvsimport: add test illustrating a bug in cvsps
Yet more tests without fixing anything...
* jc/clone-branch-rebase (Tue Mar 10 01:20:42 2009 -0700) 2 commits
+ Improve "git branch --tracking" output
+ Make git-clone respect branch.autosetuprebase
This is a rewrite of a patch from Pat Notz.
* kb/tracking-count-no-merges (Wed Mar 4 18:47:39 2009 +0100) 1 commit
+ stat_tracking_info(): only count real commits
This gives the merge commits zero weight when talking about how many
commits you have ahead (or behind) of the branch you are tracking. Even
though I agree that they should carry much less weight than the "real"
commits, because your repeated merge from the other branch does not really
add any real value to the end result, giving them absolute zero weight
somehow feels wrong. At least it shows that your have been _active_ on the
branch. But I do not feel very strongly about it.
* js/rebase-i-opt (Tue Mar 3 10:55:31 2009 +0100) 1 commit
+ rebase -i: avoid 'git reset' when possible
* kb/checkout-optim (Sun Mar 8 17:22:51 2009 -0400) 18 commits
+ Makefile: Set compiler switch for USE_NSEC
+ Create USE_ST_TIMESPEC and turn it on for Darwin
+ Not all systems use st_[cm]tim field for ns resolution file
timestamp
+ Record ns-timestamps if possible, but do not use it without
USE_NSEC
+ write_index(): update index_state->timestamp after flushing to
disk
+ verify_uptodate(): add ce_uptodate(ce) test
+ make USE_NSEC work as expected
+ fix compile error when USE_NSEC is defined
+ check_updates(): effective removal of cache entries marked
CE_REMOVE
+ lstat_cache(): print a warning if doing ping-pong between cache
types
+ show_patch_diff(): remove a call to fstat()
+ write_entry(): use fstat() instead of lstat() when file is open
+ write_entry(): cleanup of some duplicated code
+ create_directories(): remove some memcpy() and strchr() calls
+ unlink_entry(): introduce schedule_dir_for_removal()
+ lstat_cache(): swap func(length, string) into func(string, length)
+ lstat_cache(): generalise longest_match_lstat_cache()
+ lstat_cache(): small cleanup and optimisation
* mv/parseopt-ls-files (Sat Mar 7 20:27:22 2009 -0500) 4 commits
+ ls-files: fix broken --no-empty-directory
+ t3000: use test_cmp instead of diff
+ parse-opt: migrate builtin-ls-files.
+ Turn the flags in struct dir_struct into a single variable
The tip one was a subject for further discussion, but nothing is queued
yet.
* js/remote-improvements (Sun Mar 8 00:10:33 2009 -0800) 23 commits
+ builtin-remote.c: no "commented out" code, please
+ builtin-remote: new show output style for push refspecs
+ builtin-remote: new show output style
+ remote: make guess_remote_head() use exact HEAD lookup if it is
available
+ builtin-remote: add set-head subcommand
+ builtin-remote: teach show to display remote HEAD
+ builtin-remote: fix two inconsistencies in the output of "show
<remote>"
+ builtin-remote: make get_remote_ref_states() always populate
states.tracked
+ builtin-remote: rename variables and eliminate redundant function
call
+ builtin-remote: remove unused code in get_ref_states
+ builtin-remote: refactor duplicated cleanup code
+ string-list: new for_each_string_list() function
+ remote: make match_refs() not short-circuit
+ remote: make match_refs() copy src ref before assigning to
peer_ref
+ remote: let guess_remote_head() optionally return all matches
+ remote: make copy_ref() perform a deep copy
+ remote: simplify guess_remote_head()
+ move locate_head() to remote.c
+ move duplicated ref_newer() to remote.c
+ move duplicated get_local_heads() to remote.c
+ refactor find_ref_by_name() to accept const list
+ add basic http clone/fetch tests
+ test scripts: refactor start_httpd helper
* fc/parseopt-config (Sat Mar 7 12:14:05 2009 -0500) 9 commits
+ config: set help text for --bool-or-int
+ git config: don't allow --get-color* and variable type
+ git config: don't allow extra arguments for -e or -l.
+ git config: don't allow multiple variable types
+ git config: don't allow multiple config file locations
+ git config: reorganize to use parseopt
+ git config: reorganize get_color*
+ git config: trivial rename in preparation for parseopt
+ git_config(): not having a per-repo config file is not an error
* mh/cvsimport-tests (Mon Feb 23 06:08:14 2009 +0100) 5 commits
- Add a test of "git cvsimport"'s handling of tags and branches
- Add some tests of git-cvsimport's handling of vendor branches
- Test contents of entire cvsimported "master" tree contents
- Use CVS's -f option if available (ignore user's ~/.cvsrc file)
- Start a library for cvsimport-related tests
Tests without fixes are of dubious value. Any takers?
* tr/maint-1.6.0-send-email-irt (Sun Mar 1 23:45:41 2009 +0100) 1 commit
+ send-email: respect in-reply-to regardless of threading
Tests?
* js/notes (Wed Feb 18 11:17:27 2009 -0800) 14 commits
- tests: fix "export var=val"
- notes: refuse to edit notes outside refs/notes/
- t3301: use test_must_fail instead of !
- t3301: fix confusing quoting in test for valid notes ref
- notes: use GIT_EDITOR and core.editor over VISUAL/EDITOR
- notes: only clean up message file when editing
- handle empty notes gracefully
- git notes show: test empty notes
- git-notes: fix printing of multi-line notes
- notes: fix core.notesRef documentation
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
Rebased and then kicked back to 'pu' to give the author a chance to
rearrange if necessary.
----------------------------------------------------------------
[On Hold]
* jc/deny-delete-current-1.7.0 (Mon Feb 9 00:19:46 2009 -0800) 1 commit
- receive-pack: default receive.denyDeleteCurrent to refuse
* jc/refuse-push-to-current-1.7.0 (Wed Feb 11 02:28:03 2009 -0800) 1 commit
- Refuse updating the current branch in a non-bare repository via
push
These are for 1.7.0, but the messages when they trigger together may need
to be rethought.
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This was only meant as a weatherballoon to help facilitate discussion.
Will be discarded.
^ permalink raw reply
* Re: Help understanding "rebase"
From: Michael J Gruber @ 2009-03-11 9:24 UTC (permalink / raw)
To: Brandon Casey; +Cc: John M. Dlugosz, git
In-Reply-To: <KVXTFwpJn-0uEQYfgfg9YwrrimNYx6hbxe73y6qLYxfHYZH9eE4N4g@cipher.nrlssc.navy.mil>
Brandon Casey venit, vidit, dixit 10.03.2009 22:30:
> John M. Dlugosz wrote:
>> Here is the situation: An old topic branch containing 3 commits. A dev
>> branch that has recently been merged. To catch up the topic's work
>> before adding it to dev, I expected that rebase would do what I ended up
>> doing manually, detailed below.
>>
>> Instead, it crunched away for a long time and gave errors applying patches.
>>
>> So I did it manually by checking out dev, then cherry-picking each of
>> the three commits. Actually, this left it on top of dev, but suppose I
>> had created a new branch at dev, cherry-picked the stuff from the old
>> topic branch, and then deleted the old topic branch. Now I have a new
>> topic branch with the rebased changes, albeit with a different branch
>> name. Point is, there were no conflicts and the changes were simple, so
>> cherry-picking each node was clean.
>>
>> So, what did the rebase command try to do? I think it may have
>> something to do with finding a common root between the topic and dev,
>> which, due to the merge, was a long way back. Something like this:
>>
>> o--o-- ... --o
>> / \
>> A--...--B-- ... --C--D <== dev
>> \
>> q--r--s <== topic
>>
>>
>> I was able to cherry-pick q,r,s on top of D without any issues. So why
>> did rebase get in such a tizzy?
> It may help those who know the internals of git-rebase if you supplied the
> commands you used and your git version.
>
> So, you're saying you did
>
> git checkout topic
> git rebase dev
>
> or the equivalent
>
> git rebase dev topic
>
> ? Are you sure you didn't get the arguments to rebase reversed?
>
> -brandon
>
That happens very easily: You want to rewrite dev using rebase, so you
check out dev. You want to rebase the topic branch, so you run "git
rebase topic". Very logical, but the wrong way round... The doc is
clear, though.
A useful mnemonic is that git rebase A B is about the commits A..B (B
defaulting to the current branch), and that the new B after rebasing will be
B' = C + (A..B)
where C is the value of --onto, which defaults to A. The point of rebase
is that A + (A..B) does not equal B in general, even though A..B=^A B ;)
git rebase A does not rewrite/rebase A! I'll think about a concise first
paragraph for git-rebase.txt.
Michael
^ permalink raw reply
* Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 9:04 UTC (permalink / raw)
To: git
In-Reply-To: <ab9fa62a0903102317l3a7322f7w5e4d9ba0e02af37b@mail.gmail.com>
hello,
On Wed, Mar 11, 2009 at 11:26 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
>
> On Wed, 11 Mar 2009, Saurabh Gupta wrote:
>
> >
> > /*About GSoC GIT ideas;
> > */Here are the ideas which I found to be interested in. Although, I
> > would like to discuss any other idea than these in GIT organization.
> >
> > *1) Domain specific merge helpers*
> > Intelligence in the merger can be put which modifies the source file
> > according the format. Different file formats can be put in the merger
> > to support.
>
> This is something I've thought would be really handy for making git more
> widely useful. The hard part, of course, is coming up with useful
> alternative merge algorithms which work for formats that the usual merge
> doesn't handle. The infrastructure is mostly there (git supports declaring
> the types of files), but there's no point in support for running a
> type-specific merger until there are actually type-specific mergers to
> run.
>
> Do you have ideas on what formats you'd try to merge, and how?
Well, What I think is to implement file formats other than text like
that written on wiki i.e. latex, xml, or even any database file (db
file). Another idea (although it can be weired also) is to implement
the new file formats in the plug-in formats. For example, to
incorporate the merger engine for a new file format, a plug-in is
created and can be integrated with the present merger in the git.
However, I am not sure how much valid is this idea to make the present
merger in git to be compatible with the plug-ins for enabling newer
file formats.
Any new idea or suggestions are welcome.
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-11 9:02 UTC (permalink / raw)
To: David Symonds; +Cc: git
In-Reply-To: <ee77f5c20903110159l1cda4c3dnc9588c1352905932@mail.gmail.com>
On Wed, Mar 11, 2009 at 2:29 PM, David Symonds <dsymonds@gmail.com> wrote:
>
> On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta
> <saurabhgupta1403@gmail.com> wrote:
>
> > *1) Domain specific merge helpers*
> > Intelligence in the merger can be put which modifies the source file
> > according the format. Different file formats can be put in the merger
> > to support.
>
> I don't think that's Git specific, though it still might be reasonable
> to be done as a Git GSoC project. I'm sure other VCSs would find that
> useful, and even folk who aren't using VCSs might benefit from it.
All right.
Can you suggest me another idea or any aim which GIT will mostly be
interested in. I am also looking over other ideas and areas where more
improvement can be put.
Thanks...
>
> Dave.
--
Saurabh Gupta
Senior,
Electronics and Communication Engg.
NSIT,New Delhi, India
^ permalink raw reply
* Re: Generalised bisection
From: Ealdwulf Wuffinga @ 2009-03-11 8:59 UTC (permalink / raw)
To: Christian Couder; +Cc: Git List, John Tapsell, Ingo Molnar
In-Reply-To: <200903100808.15875.chriscool@tuxfamily.org>
On Tue, Mar 10, 2009 at 7:08 AM, Christian Couder
<chriscool@tuxfamily.org> wrote:
> I will try to have a look at the end of this week.
> But do you want it to be integrated with Git or do you want it to be an
> independant project that works with many different version control system?
Hmm. Whatever works, I guess. On the one hand the code does seem
naturally generic. On the other hand, it's good if users don't
have to separately obtain an extra package to use it. Supposing that
the algorithm proves useful, would the git project be okay with an
extra dependency, or would you want to integrate it? Right now it's in
python, which I understand is an obstacle to integration.
In the short term, I assume the algorithm needs to prove its
usefulness before either being integrated or added as a dependency.
It seems the majority of potential users - developers of code of the
sort likely to have intermittent bugs, such as the kernel or xorg -
use git,
so I would like it to be as easy as possible for git users to try it
out. Maybe it could live in the contrib directory for a while?
Ealdwulf
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: David Symonds @ 2009-03-11 8:59 UTC (permalink / raw)
To: Saurabh Gupta; +Cc: git
In-Reply-To: <49B74373.3090609@gmail.com>
On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta
<saurabhgupta1403@gmail.com> wrote:
> *1) Domain specific merge helpers*
> Intelligence in the merger can be put which modifies the source file
> according the format. Different file formats can be put in the merger
> to support.
I don't think that's Git specific, though it still might be reasonable
to be done as a Git GSoC project. I'm sure other VCSs would find that
useful, and even folk who aren't using VCSs might benefit from it.
Dave.
^ permalink raw reply
* Re: [PATCH v2] git-clone: Add option --branch to override initial branch
From: Paolo Ciarrocchi @ 2009-03-11 8:52 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, torarnv, Junio C Hamano, Johannes Schindelin
In-Reply-To: <94a0d4530903090901o6e8c2a40k676387f90ee461b3@mail.gmail.com>
[restored the CC list]
On Mon, Mar 9, 2009 at 5:01 PM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Mon, Mar 9, 2009 at 4:39 PM, Paolo Ciarrocchi
> <paolo.ciarrocchi@gmail.com> wrote:
[...]
>> I wrote a comment about the --branch approach a couple of days ago, dunno why
>> but this thread never reached my inbox (replying via gmame web interface).
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/112527
>>
>> As I wrote in my post a friend of mine, new to git, was looking for the
>> possibility of cloning a repo and automatically checkout a specific branch.
>
> Yeah, I also would like this option... one-liner for people that don't
> know git at all.
>
> me: you want my code? just run this command.
Yes, that is what my friend was lookin for.
I told him to use the following procedure:
$ git clone -n URL
$ git checkout -b foo origin/bar
He is now an almost happy git user :-).
That being said, I see the following command as an improvement over
the actual GIT UI:
$ git clone git://URI -b bar
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply
* Re: [BUG] - git-read-tree segfaults
From: Jiri Olsa @ 2009-03-11 7:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903102120290.14295@intel-tinevez-2-302>
On Tue, Mar 10, 2009 at 9:21 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Tue, 10 Mar 2009, Jiri Olsa wrote:
>
>> mb=$($GIT merge-base HEAD yyy)
>> $GIT read-tree $mb HEAD yyy
>
> While I agree that it is a bad thing for Git to segfault, I think this
> here is a pilot error. You try to read 3 trees at the same time, but not
> perform a merge. IMHO you want to add -m at least.
agreed, I've already said I executed it like this by an accident...
it was easy to recreate so I shared... I'm not saying it is a show stopper :)
jirka
>
> Ciao,
> Dscho
>
>
^ permalink raw reply
* Re: git-p4 workflow suggestions?
From: Christian Couder @ 2009-03-11 7:03 UTC (permalink / raw)
To: Sam Hocevar; +Cc: git
In-Reply-To: <20090310095729.GA27280@zoy.org>
Le mardi 10 mars 2009, Sam Hocevar a écrit :
> On Tue, Mar 10, 2009, Christian Couder wrote:
> > > I have modified git and git-p4 to a point where they are usable in
> > > my work environment. I am now faced with a new problem: Perforce's
> > > composite workspaces. They allow you to "mount" parts of the repo
> > > onto other directories, even nonempty ones.
> >
> > It looks like SVN externals. So I think you should read about "git
> > submodule".
> >
> > There is this related link on the wiki:
> >
> > http://blog.alieniloquent.com/2008/03/08/git-svn-with-svnexternals/
>
> Unfortunately submodules are considered separate repositories, so if
> I have /include and /src as submodules, I cannot commit atomically to
> both. Or can I? That's probably my strongest requirement.
I thought that you can commit in /include then in /src and then in the
supermodule. This way you should have an atomic commit in the supermodule
with both changes. But I don't know much about submodules.
> > You may also want to search the mailing list as this subject has often
> > been discussed.
>
> I did skim through the archives, but couldn't find much. There was
> this discussion: http://kerneltrap.org/mailarchive/git/2006/11/28/231515
> where the idea of Perforce-like workspaces was apparently dismissed as
> being "a mess".
Perhaps. Anyway I think there are patches about submodules quite often on
the list and it seems a hot topic as there is an entry on the GSoC2009 idea
page:
http://git.or.cz/gitwiki/SoC2009Ideas
On this page you may also be interested by the "Narrow and Sparse clone
support" idea.
Best regards,
Christian.
PS: it would be nice to put me in the CC header of your emails when you
reply to me.
^ permalink raw reply
* How newbies create remote repositories
From: Bernie Innocenti @ 2009-03-11 6:59 UTC (permalink / raw)
To: git
Here's another usability problem report from my friends who
are learning their way to Git from previous experience with
Subversion and Mercurial.
Three of them confessed they couldn't find a simple recipe
to setup remote repositories, after looking in obvious
places such as the git-push manpage.
Each one could figure it out independently after some time, coming
up with a variety of creative strategies:
Strategy 1:
client$ ssh server
server$ mkdir foo.git
server$ cd foo.git
server$ git init --bare --shared
server$ exit
client$ git push --mirror server:foo.git
Problem: Does not setup the remote for you.
Solution: Would be nice if "git push <URL>" could give this tip
Problem: Requires a full unrestricted shell on the server
Solution: If "git init <dir>" was supported, one could do
ssh server git init --bare --shared foo.git
Strategy 2:
client$ ssh server
server$ mkdir foo.git
server$ cd foo.git
server$ git init --bare --shared
server$ exit
client$ git clone server:foo.git .
client$ git add .
client$ git commit
client$ git push
Problem: only works if you had no local repository yet
Strategy 3:
client$ scp -r .git server:foo.git
client$ cd ..
client$ rm -r foo
client$ git clone server:foo.git
Problem: the user checks out the repository from scratch
to properly add the remote
Solution: "git pull" might suggest to use "git remote".
A simple "git remote create" or "git remote new" along with a
reference to it in the manpage of "git push" might have helped
these users.
--
// Bernie Innocenti - http://www.codewiz.org/
\X/ Sugar Labs - http://www.sugarlabs.org/
^ permalink raw reply
* Re: setting up tracking on push
From: Jeff King @ 2009-03-11 6:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jay Soffian, Marc Branchaud, Miles Bader, git
In-Reply-To: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org>
On Tue, Mar 10, 2009 at 09:37:21PM -0700, Junio C Hamano wrote:
> In any case, I find these "branch --retrack" proposals too confusing and
> probably overengineered.
I agree. I was hoping to find something that _wasn't_ confusing, but I
don't think we've succeeded.
> I need to ask a more fundamental question. Is it really useful for people
> to be able to re-track arbitrary remote/branch with an existing branch?
I do it occasionally, but I have never had a problem with editing
.git/config.
My use case is usually something like:
1. make an experimental commit on some long-running branch like 'next'
or 'master'
2. realize it's going to take several commits and would work better as
a topic branch
3. git checkout -b topic
in which case I have no tracking setup. But if I had realized it was
going to be a topic in the first place and done "git checkout -b topic
origin/master" then I would.
But again, I don't have a problem with editing .git/config. I was trying
in this thread to respond to user request.
-Peff
^ permalink raw reply
* Re: [PATCH] Give error when no remote is configured
From: Bernie Innocenti @ 2009-03-11 6:19 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, git, Giovanni Bajo
In-Reply-To: <alpine.LNX.1.00.0903110139450.19665@iabervon.org>
Daniel Barkalow wrote:
> When there's no explicitly-named remote, we use the remote specified
> for the current branch, which in turn defaults to "origin". But it
> this case should require the remote to actually be configured, and not
> fall back to the path "origin".
> [...]
Thanks, works like a charm!
--
// Bernie Innocenti - http://www.codewiz.org/
\X/ Sugar Labs - http://www.sugarlabs.org/
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Daniel Barkalow @ 2009-03-11 5:56 UTC (permalink / raw)
To: Saurabh Gupta; +Cc: git
In-Reply-To: <49B74373.3090609@gmail.com>
On Wed, 11 Mar 2009, Saurabh Gupta wrote:
> hello everyone,
>
> /*First, a brief introduction about me: */
> I am Saurabh Gupta from India. I am a senior engineering student. I
> have been working for open source projects for a long time and I was a
> *GSoC student in 2008* where I successfully completed my project under
> the organization Openmoko (www.openmoko.org
> <http://www.openmoko.org/>). In 2008 winters, I had my internship at
> *Adobe Inc.* where I worked on the package management system using
> C++ and sqlite library. I have a long experience in programming in C,
> C++, Python and other languages. Currently, my final year project at
> university is about the automatic data logging system in which I am
> working upon socket programming in C, C++, MYSQL and setting up an
> intra-college website using LAMP. I am a user of svn extensively and
> use git sometimes.
>
>
> /*About GSoC GIT ideas;
> */Here are the ideas which I found to be interested in. Although, I
> would like to discuss any other idea than these in GIT organization.
>
> *1) Domain specific merge helpers*
> Intelligence in the merger can be put which modifies the source file
> according the format. Different file formats can be put in the merger
> to support.
This is something I've thought would be really handy for making git more
widely useful. The hard part, of course, is coming up with useful
alternative merge algorithms which work for formats that the usual merge
doesn't handle. The infrastructure is mostly there (git supports declaring
the types of files), but there's no point in support for running a
type-specific merger until there are actually type-specific mergers to
run.
Do you have ideas on what formats you'd try to merge, and how?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Give error when no remote is configured
From: Daniel Barkalow @ 2009-03-11 5:47 UTC (permalink / raw)
To: bernie, Junio C Hamano; +Cc: git, Giovanni Bajo
When there's no explicitly-named remote, we use the remote specified
for the current branch, which in turn defaults to "origin". But it
this case should require the remote to actually be configured, and not
fall back to the path "origin".
Possibly, the config file's "remote = something" should require the
something to be a configured remote instead of a bare repository URL,
but we actually test with a bare repository URL.
In fetch, we were giving the sensible error message when coming up
with a URL failed, but this wasn't actually reachable, so move that
error up and use it when appropriate.
In push, we need a new error message, because the old one (formerly
unreachable without a lot of help) used the repo name, which was NULL.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
---
I think the main way to reach this in actual usage would be to use git-svn
to create a repository and then forget that you used it and therefore
don't have an origin.
builtin-fetch.c | 6 +++---
builtin-push.c | 7 +++++--
remote.c | 30 +++++++++++++++++++++++++++---
3 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 1e4a3d9..7fb35fc 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -636,6 +636,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
else
remote = remote_get(argv[0]);
+ if (!remote)
+ die("Where do you want to fetch from today?");
+
transport = transport_get(remote, remote->url[0]);
if (verbosity >= 2)
transport->verbose = 1;
@@ -648,9 +651,6 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
if (depth)
set_option(TRANS_OPT_DEPTH, depth);
- if (!transport->url)
- die("Where do you want to fetch from today?");
-
if (argc > 1) {
int j = 0;
refs = xcalloc(argc + 1, sizeof(const char *));
diff --git a/builtin-push.c b/builtin-push.c
index 122fdcf..ca36fb1 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -53,8 +53,11 @@ static int do_push(const char *repo, int flags)
int i, errs;
struct remote *remote = remote_get(repo);
- if (!remote)
- die("bad repository '%s'", repo);
+ if (!remote) {
+ if (repo)
+ die("bad repository '%s'", repo);
+ die("No destination configured to push to.");
+ }
if (remote->mirror)
flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
diff --git a/remote.c b/remote.c
index d7079c6..199830e 100644
--- a/remote.c
+++ b/remote.c
@@ -38,6 +38,7 @@ static int branches_nr;
static struct branch *current_branch;
static const char *default_remote_name;
+static int explicit_default_remote_name;
static struct rewrite **rewrite;
static int rewrite_alloc;
@@ -104,6 +105,16 @@ static void add_url_alias(struct remote *remote, const char *url)
add_url(remote, alias_url(url));
}
+static struct remote *get_remote_by_name(const char *name)
+{
+ int i;
+ for (i = 0; i < remotes_nr; i++) {
+ if (!strcmp(name, remotes[i]->name))
+ return remotes[i];
+ }
+ return NULL;
+}
+
static struct remote *make_remote(const char *name, int len)
{
struct remote *ret;
@@ -330,8 +341,10 @@ static int handle_config(const char *key, const char *value, void *cb)
if (!value)
return config_error_nonbool(key);
branch->remote_name = xstrdup(value);
- if (branch == current_branch)
+ if (branch == current_branch) {
default_remote_name = branch->remote_name;
+ explicit_default_remote_name = 1;
+ }
} else if (!strcmp(subkey, ".merge")) {
if (!value)
return config_error_nonbool(key);
@@ -643,11 +656,22 @@ static int valid_remote_nick(const char *name)
struct remote *remote_get(const char *name)
{
struct remote *ret;
+ int name_given = 0;
read_config();
- if (!name)
+ if (name)
+ name_given = 1;
+ else {
name = default_remote_name;
- ret = make_remote(name, 0);
+ name_given = explicit_default_remote_name;
+ }
+ if (name_given)
+ ret = make_remote(name, 0);
+ else {
+ ret = get_remote_by_name(name);
+ if (!ret)
+ return NULL;
+ }
if (valid_remote_nick(name)) {
if (!ret->url)
read_remotes_file(ret);
--
1.6.2.104.g7aeb2.dirty
^ permalink raw reply related
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 5:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Marc Branchaud, Miles Bader, git
In-Reply-To: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 12:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> I need to ask a more fundamental question. Is it really useful for people
> to be able to re-track arbitrary remote/branch with an existing branch?
Actually, for me, I find sometimes I've forgotten to setup tracking,
or I've setup tracking and don't want it. I just fire up an editor on
.git/config, or use git config, but I would appreciate an easy way to
add/remove tracking to a branch after the fact.
j.
^ permalink raw reply
* Re: setting up tracking on push
From: Miles Bader @ 2009-03-11 5:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jay Soffian, Marc Branchaud, git
In-Reply-To: <fc339e4a0903102156q4b61b712j6c7b4daaef6f163@mail.gmail.com>
Miles Bader <miles@gnu.org> writes:
> I agree, and that's the use-case that prompted my original query. I
> very often create a new branch locally, and later push it to origin
> with an intent to subsequently keep it synced with the new remote
> branch.
Oh, and I also always use the syntax:
git push origin BRANCH_NAME
As the (apparent) objection adding "git push --track" was the question
of what the behavior would be in the general case (where lots of
branches can be pushed), maybe restricting "--track" to only specific
cases would be a possible solution?
-Miles
--
97% of everything is grunge
^ permalink raw reply
* Re: setting up tracking on push
From: Miles Bader @ 2009-03-11 4:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Jay Soffian, Marc Branchaud, git
In-Reply-To: <7vwsaw7jzy.fsf@gitster.siamese.dyndns.org>
On Wed, Mar 11, 2009 at 1:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> And for that use case, I find it sensible if we had a way to easily say
> "This branch hasn't been tracking anything so far (because it is the
> originator of the history), but now it will give up its authority and
> start tracking the one it is pushing into", and it would make sense to
> somehow link that to the invocation of "git push".
I agree, and that's the use-case that prompted my original query. I
very often create a new branch locally, and later push it to origin
with an intent to subsequently keep it synced with the new remote
branch.
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Google Summer of Code 2009: GIT
From: Saurabh Gupta @ 2009-03-11 4:52 UTC (permalink / raw)
To: git
hello everyone,
/*First, a brief introduction about me: */
I am Saurabh Gupta from India. I am a senior engineering student. I
have been working for open source projects for a long time and I was a
*GSoC student in 2008* where I successfully completed my project under
the organization Openmoko (www.openmoko.org
<http://www.openmoko.org/>). In 2008 winters, I had my internship at
*Adobe Inc.* where I worked on the package management system using
C++ and sqlite library. I have a long experience in programming in C,
C++, Python and other languages. Currently, my final year project at
university is about the automatic data logging system in which I am
working upon socket programming in C, C++, MYSQL and setting up an
intra-college website using LAMP. I am a user of svn extensively and
use git sometimes.
/*About GSoC GIT ideas;
*/Here are the ideas which I found to be interested in. Although, I
would like to discuss any other idea than these in GIT organization.
*1) Domain specific merge helpers*
Intelligence in the merger can be put which modifies the source file
according the format. Different file formats can be put in the merger
to support.
I am looking forward to get feedback and suggestions for this and to
discuss the ideas. I would like to contribute GIT this summer if I get
a chance through GSoC. If not, then still, I would remain in contact
with the community to contribute in the best possible manner I can.
^ permalink raw reply
* Re: setting up tracking on push
From: Junio C Hamano @ 2009-03-11 4:37 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311020409.GA31365@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> # track origin/master with a different branch
> git branch --track=origin/master other_branch
Isn't this one confusing with "git branch other_branch origin/master" (I
thought --track is the default these days)?
In any case, I find these "branch --retrack" proposals too confusing and
probably overengineered.
I need to ask a more fundamental question. Is it really useful for people
to be able to re-track arbitrary remote/branch with an existing branch?
The only use case I've heard in this thread and nearby is where you are
the one who started the history of the branch, and pushed it into a public
repository as a new branch, making the result _the_ most authoritative
one. After that, everybody else will be able to have a local branch that
tracks the authoritative one with "branch --track frotz origin/frotz", and
you will be the only one left unable to do so because you already have
that frotz branch.
And for that use case, I find it sensible if we had a way to easily say
"This branch hasn't been tracking anything so far (because it is the
originator of the history), but now it will give up its authority and
start tracking the one it is pushing into", and it would make sense to
somehow link that to the invocation of "git push".
Side note. I would also accept "It is only one person in the world,
who can edit .git/config and be done with it; why bother complicate
the UI for other people" as a valid argument against it, though ;-).
In that "my private branch gave autority to the branch at my public
repository" case, it is of course easy to re-clone (or "branch -m" away
and then re-fetch) like everybody else, but then you would lose the reflog
from the time before the branch went public, so it is not a solution but a
poor workaround.
I somehow think it would not make any sense to say "This branch used to
track that branch but now it will start tracking this other one". People
of course can come up with contrived example to claim it is a useful
operation, but in real life, would it really be? "The authoritative
repository has moved" is not an example. It would merely be a change in
remote.<name>.url. "The upstream renamed the branch" is not an example
either. It falls into "Don't do that, then. It will confuse everybody"
case.
^ permalink raw reply
* Re: Obfuscated error message
From: Bernie Innocenti @ 2009-03-11 4:28 UTC (permalink / raw)
To: git; +Cc: Giovanni Bajo
In-Reply-To: <49B73D1A.4050605@codewiz.org>
Bernie Innocenti wrote:
> A friend who uses Mercurial pointed this out as a reson why
> Git is evil:
>
> rasky@lilax:~/src$ git clone git://www.develer.com/doesnt-exist
> Initialized empty Git repository in /home/rasky/src/doesnt-exist/.git/
> fatal: The remote end hung up unexpectedly
>
> Plus, the directory was not really there :-)
>
> rasky@lilax:~/src$ hg clone hg://www.develer.com/doesnt-exist
> abort: repository hg://www.develer.com/doesnt-exist not found!
>
> rasky@lilax:~/src$ svn co svn://www.develer.com/doesnt-exist
> svn: URL 'svn://www.develer.com/doesnt-exist' doesn't exist
>
And another really nasty one:
trinity:~/foo$ git init
Initialized empty shared Git repository in /home/bernie/foo/.git/
trinity:~/foo$ git push
fatal: 'origin': unable to chdir or not a git archive
fatal: The remote end hung up unexpectedly
Both are with git HEAD as of today.
--
// Bernie Innocenti - http://www.codewiz.org/
\X/ Sugar Labs - http://www.sugarlabs.org/
^ permalink raw reply
* Obfuscated error message
From: Bernie Innocenti @ 2009-03-11 4:24 UTC (permalink / raw)
To: git; +Cc: Giovanni Bajo
A friend who uses Mercurial pointed this out as a reson why
Git is evil:
rasky@lilax:~/src$ git clone git://www.develer.com/doesnt-exist
Initialized empty Git repository in /home/rasky/src/doesnt-exist/.git/
fatal: The remote end hung up unexpectedly
Plus, the directory was not really there :-)
rasky@lilax:~/src$ hg clone hg://www.develer.com/doesnt-exist
abort: repository hg://www.develer.com/doesnt-exist not found!
rasky@lilax:~/src$ svn co svn://www.develer.com/doesnt-exist
svn: URL 'svn://www.develer.com/doesnt-exist' doesn't exist
--
// Bernie Innocenti - http://www.codewiz.org/
\X/ Sugar Labs - http://www.sugarlabs.org/
^ permalink raw reply
* Re: setting up tracking on push
From: Jay Soffian @ 2009-03-11 4:15 UTC (permalink / raw)
To: Jeff King; +Cc: Marc Branchaud, Miles Bader, git
In-Reply-To: <20090311035701.GA6089@coredump.intra.peff.net>
On Tue, Mar 10, 2009 at 11:57 PM, Jeff King <peff@peff.net> wrote:
>> -u w/o --track/--no-track is a usage error.
>
> Then what is the point of "-u"? You said before that it was a new
> operation with room for future growth of additional options. Either it
> is _just_ for --track, in which case I think you are better to have a
> single option representing the notion of "update the tracking setup", or
> it isn't, in which case it needs to have room for future expansion.
For *now*, it is just for --track/--no-track, since I can't think of
anything sensible that "-u" without --track nor --no-track would do.
So it means, update the branch config, but you have to tell it what
aspect of the branch config to update.
I agree that currently, a single option could do here, but I can't
think of a good one. --add-tracking and --delete-tracking? I was
trying to re-use the fact that we already have --track and --no-track,
but I needed some way to differentiate the mode from "create a new
branch". Hence -u.
j.
^ 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