* [ANNOUNCE] git-cola 1.4.1.2
From: David Aguilar @ 2010-01-01 1:48 UTC (permalink / raw)
To: git
git-cola is a powerful GUI for Git written in Python/PyQt4
git-cola v1.4.1.2 has been tagged and released:
* git clone git://github.com/davvid/git-cola.git
* http://github.com/davvid/git-cola
* http://cola.tuxfamily.org/
I haven't sent an announcement in a long time but we've
been quite busy working on enhancements nonetheless.
The release notes below summarize all changes since 1.3.8
in case you haven't kept up with the latest cola.
NYE is fast approaching here on the west coast so I've got a
party to catch. Thus, this is the last git-cola for 2009 ;-)
Happy New Years everybody!
git-cola v1.4.1.2
=================
Usability, bells and whistles
-----------------------------
* It is now possible to checkout from the index as well
as from `HEAD`. This corresponds to the
`Removed Unstaged Changes` action in the `Repository Status` tool.
* The `remote` dialogs (fetch, push, pull) are now slightly
larger by default.
* Bookmarks can be selected when `git-cola` is run outside of a Git repository.
* Added more user documentation. We now include many links to
external git resources.
Fixes
-----
* Fixed a missing ``import`` when showing `right-click` actions
for unmerged files in the `Repository Status` tool.
* ``git update-index --refresh`` is no longer run everytime
``git cola version`` is run.
* Don't try to watch non-existant directories when using `inotify`.
Packaging
---------
* The ``Makefile`` will now conditionally include a ``config.mak``
file located at the root of the project. This allows for user
customizations such as changes to the `prefix` variable
to be stored in a file so that custom settings do not need to
be specified every time on the command-line.
* The build scripts no longer require a ``.git`` directory to
generate the ``builtin_version.py`` module. The release tarballs
now include a ``version`` file at the root of the project which
is used in lieu of having the Git repository available.
This allows for ``make clean && make`` to function outside of
a Git repository.
* Added maintainer's ``make dist`` target to the ``Makefile``.
* The built-in `simplejson` and `jsonpickle` libraries can be
excluded from ``make install`` by specifying the ``standalone=true``
`make` variable. For example, ``make standalone=true install``.
This corresponds to the ``--standalone`` option to ``setup.py``.
git-cola v1.4.1.1
=================
Usability, bells and whistles
-----------------------------
* We now use patience diff by default when it is available via
`git diff --patience`.
* Allow closing the `cola classic` tool with `Ctrl+W`.
* Update desktop menu entry to read `Cola Git GUI`.
Fixes
-----
* Fixed an unbound variable error in the `push` dialog.
Packaging
---------
* Don't include `simplejson` in MANIFEST.in.
* Update desktop entry to read `Cola Git GUI`.
git-cola v1.4.1
===============
This feature release adds two new features directly from
`git-cola`'s github issues backlog. On the developer
front, further work was done towards modularizing the code base.
Usability, bells and whistles
-----------------------------
* Dragging and dropping patches invokes `git-am`
http://github.com/davvid/git-cola/issues/closed#issue/3
* A dialog to allow opening or cloning a repository
is presented when `git-cola` is launched outside of a git repository.
http://github.com/davvid/git-cola/issues/closed/#issue/22
* Warn when `push` is used to create a new branch
http://github.com/davvid/git-cola/issues/closed#issue/35
* Optimized startup time by removing several calls to `git`.
Portability
-----------
* `git-cola` is once again compatible with PyQt 4.3.x.
Developer
---------
* `cola.gitcmds` was added to factor out git command-line utilities
* `cola.gitcfg` was added for interacting with `git-config`
* `cola.models.browser` was added to factor out repobrowser data
* Added more tests
git-cola v1.4.0.5
=================
Fixes
-----
* Fix launching external applications on Windows
* Ensure that the `amend` checkbox is unchecked when switching modes
* Update the status tree when amending commits
git-cola v1.4.0.4
=================
Packaging
---------
* Fix Lintian warnings
git-cola v1.4.0.3
=================
Fixes
-----
* Fix X11 warnings on application startup
git-cola v1.4.0.2
=================
Fixes
-----
* Added missing 'Exit Diff Mode' button for 'Diff Expression' mode
http://github.com/davvid/git-cola/issues/closed/#issue/31
* Fix a bug when initializing fonts on Windows
http://github.com/davvid/git-cola/issues/closed/#issue/32
git-cola v1.4.0.1
=================
Fixes
-----
* Keep entries in sorted order in the `cola classic` tool
* Fix staging untracked files
http://github.com/davvid/git-cola/issues/closed/#issue/27
* Fix the `show` command in the Stash dialog
http://github.com/davvid/git-cola/issues/closed/#issue/29
* Fix a typo when loading merge commit messages
http://github.com/davvid/git-cola/issues/closed/#issue/30
git-cola v1.4.0
===============
This release focuses on a redesign of the git-cola user interface,
a tags interface, and better integration of the `cola classic` tool.
A flexible interface based on configurable docks is used to manage the
various cola widgets.
Usability, bells and whistles
-----------------------------
* New GUI is flexible and user-configurable
* Individual widgets can be detached and rearranged arbitrarily
* Add an interface for creating tags
* Provide a fallback `SSH_ASKPASS` implementation to prompt for
SSH passwords on fetch/push/pull
* The commit message editor displays the current row/column and
warns when lines get too long
* The `cola classic` tool displays upstream changes
* `git cola --classic` launches `cola classic` in standalone mode
* Provide more information in log messages
Fixes
-----
* Inherit the window manager's font settings
* Miscellaneous PyQt4 bug fixes and workarounds
Developer
---------
* Removed all usage of Qt Designer `.ui` files
* Simpler model/view architecture
* Selection is now shared across tools
* Centralized notifications are used to keep views in sync
* The `cola.git` command class was made thread-safe
* Less coupling between model and view actions
* The status view was rewritten to use the MVC architecture
* Added more documentation and tests
git-cola v1.3.9
===============
Usability, bells and whistles
-----------------------------
* Added a `cola classic` tool for browsing the entire repository
* Handle diff expressions with spaces
* Handle renamed files
Portability
-----------
* Handle carat `^` characters in diff expressions on Windows
* Worked around a PyQt 4.5/4.6 QThreadPool bug
Documentation
-------------
* Added a keyboard shortcuts reference page
* Added developer API documentation
Fixes
-----
* Fix the diff expression used when reviewing branches
* Fix a bug when pushing branches
* Fix X11 warnings at startup
* Fix more interrupted system calls on Mac OS X
--
David
^ permalink raw reply
* Re: [PATCH] Reword -M, when in `git log`s documention, to suggest --follow
From: Alex Vandiver @ 2010-01-01 0:45 UTC (permalink / raw)
To: git
In-Reply-To: <1261428059-31286-1-git-send-email-alex@chmrr.net>
At Mon Dec 21 15:40:59 -0500 2009, Alex Vandiver wrote:
> [snip]
Any thoughts on this doc patch? I saw someone get rather frustrated
at this particular failure mode, so I'd like to be able to reassure
them that it'll get fixed.
- Alex
--
Networking -- only one letter away from not working
^ permalink raw reply
* Re: [Updated PATCH 2/2] Improve transport helper exec failure reporting
From: Johannes Sixt @ 2010-01-01 0:34 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <4B3CF118.7080404@kdbg.org>
On Donnerstag, 31. Dezember 2009, Johannes Sixt wrote:
> Ilari Liusvaara schrieb:
> > The child process can't sanely print anything. Stderr would go to
> > who knows where.
>
> Wrong - because:
> > Parent process should have much better idea what to
> > do with errors.
>
> Very correct. For this reason, the parent process assigns a stderr channel
> to the child (or does not do so to inherit its own stderr), and the child
> is expected to use it. Errors due to execvp failures are no exception, IMO
> (except ENOENT, as always).
Actually, I changed my mind: execvp failures should go to the parent's stderr,
just as all errors before the exec happens.
How about this patch for a starter? Take it with a grain of salt - I coded it
after the New Year celebration ;) I was unable to find a case quickly that
exercises die_child().
--- 8< ---
From: Johannes Sixt <j6t@kdbg.org>
Date: Fri, 1 Jan 2010 01:22:05 +0100
Subject: [PATCH] start_command: report child process setup errors to the parent's stderr
When the child process's environment is set up in start_command(), error
messages were written to wherever the parent redirected the child's stderr
channel. However, even if the parent redirected the child's stderr, errors
during this setup process, including the exec itself, are usually an
indication of a problem in the parent's environment. Therefore, the error
messages should go to the parent's stderr.
Redirection of the child's error messages is usually only used to redirect
hook error messages during client-server exchanges such that stderr goes
to the client. In these cases, hook setup errors could be regarded as
information leak.
This patch makes a copy of stderr if necessary and uses a special
die routine that is used for all die() calls so that the errors are sent to
the parent's channel.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
run-command.c | 39 ++++++++++++++++++++++++++++++++++++---
1 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/run-command.c b/run-command.c
index cf2d8f7..2480a8c 100644
--- a/run-command.c
+++ b/run-command.c
@@ -15,6 +15,23 @@ static inline void dup_devnull(int to)
close(fd);
}
+#ifndef WIN32
+static int child_err;
+
+static NORETURN void die_child(const char *err, va_list params)
+{
+ char msg[4096];
+ int len = vsnprintf(msg, sizeof(msg), err, params);
+ if (len > sizeof(msg))
+ len = sizeof(msg);
+
+ write(child_err, "fatal: ", 7);
+ write(child_err, msg, len);
+ write(child_err, "\n", 1);
+ exit(128);
+}
+#endif
+
int start_command(struct child_process *cmd)
{
int need_in, need_out, need_err;
@@ -79,6 +96,21 @@ fail_pipe:
fflush(NULL);
cmd->pid = fork();
if (!cmd->pid) {
+ /*
+ * Redirect the channel to write syscall error messages to
+ * before redirecting the process's stderr so that all die()
+ * in subsequent call paths use the parent's stderr.
+ */
+ if (cmd->no_stderr || need_err) {
+ int flags;
+ child_err = dup(2);
+ flags = fcntl(child_err, F_GETFL);
+ if (flags < 0)
+ flags = 0;
+ fcntl(child_err, F_SETFL, flags | FD_CLOEXEC);
+ set_die_routine(die_child);
+ }
+
if (cmd->no_stdin)
dup_devnull(0);
else if (need_in) {
@@ -126,9 +158,10 @@ fail_pipe:
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
- strerror(errno));
- exit(127);
+ if (errno == ENOENT)
+ exit(127);
+ else
+ die_errno("exec '%s'", cmd->argv[0]);
}
if (cmd->pid < 0)
error("cannot fork() for %s: %s", cmd->argv[0],
--
1.6.6.115.gd1ab3
^ permalink raw reply related
* Re: [PATCH v6 0/4] "git reset --merge" related improvements
From: Linus Torvalds @ 2010-01-01 0:25 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, git, Johannes Schindelin, Stephan Beyer,
Daniel Barkalow, Jakub Narebski, Paolo Bonzini, Johannes Sixt,
Stephen Boyd
In-Reply-To: <20091230055008.4475.95755.chriscool@tuxfamily.org>
On Wed, 30 Dec 2009, Christian Couder wrote:
>
> Another reroll with the following changes:
> - patches to add --keep option have been removed for now
> - documentation patch has been moved before the core code changes
> - commit messages have been improved
> - tests have been much improved thanks to Junio's suggestions
>
> Christian Couder (3):
> reset: improve mixed reset error message when in a bare repo
> Documentation: reset: add some tables to describe the different
> options
> reset: add a few tests for "git reset --merge"
>
> Stephan Beyer (1):
> reset: use "unpack_trees()" directly instead of "git read-tree"
FWIW, Ack on this version of the whole series - I don't think there is
anything controversial here, and I think avoiding the execve of read-tree
for something we have a library function for is a good thing (and the
change in behavior looks like a bug-fix to me).
And the whole "--keep" discussion can be resurrected later ;)
Linus
^ permalink raw reply
* What's cooking in git.git (Dec 2009, #06; Thu, 31)
From: Junio C Hamano @ 2010-01-01 0:10 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.
The tip of 'next' will soon be rebuilt on top of the current 'master'.
This will be the last "What's cooking" message in year 2009 ;-)
--------------------------------------------------
[New Topics]
* cc/reset-more (2009-12-30) 4 commits
- reset: use "unpack_trees()" directly instead of "git read-tree"
- reset: add a few tests for "git reset --merge"
- Documentation: reset: add some tables to describe the different options
- reset: improve mixed reset error message when in a bare repo
Resurrected from "Ejected" category. Haven't looked at it yet myself,
though...
* bg/maint-remote-update-default (2009-12-31) 1 commit
- Fix "git remote update" with remotes.defalt set
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
- Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
(merged to 'next' on 2009-12-30 at de97679)
+ reset: unbreak hard resets with GIT_WORK_TREE
* jk/push-to-delete (2009-12-30) 1 commit
- builtin-push: add --delete as syntactic sugar for :foo
* jk/run-command-use-shell (2009-12-30) 6 commits
- 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
- run-command: add "use shell" option
* mm/config-path (2009-12-30) 1 commit
- builtin-config: add --path option doing ~ and ~user expansion.
* pm/cvs-environ (2009-12-30) 1 commit
- CVS Server: Support reading base and roots from environment
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
- archive: complain about path specs that don't match anything
* so/cvsserver-update (2009-12-07) 1 commit
- cvsserver: make the output of 'update' more compatible with cvs.
* tc/clone-v-progress (2009-12-26) 4 commits
- 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
* tc/smart-http-restrict (2009-12-30) 3 commits
- Smart-http tests: Test http-backend without curl or a webserver
- Smart-http tests: Break test t5560-http-backend into pieces
- Smart-http: check if repository is OK to export before serving it
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
- bash completion: factor submodules into dirty state
--------------------------------------------------
[Cooking]
* jc/cache-unmerge (2009-12-25) 9 commits
- 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
* js/filter-branch-prime (2009-12-15) 1 commit
- filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
- tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
- octopus: remove dead code
- octopus: reenable fast-forward merges
- octopus: make merge process simpler to follow
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2009-12-24 at ff4d1d4)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- 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
* bg/maint-add-all-doc (2009-12-07) 4 commits
- squash! rm documentation--also mention add-u where we mention commit-a
- git-rm doc: Describe how to sync index & work tree
- git-add/rm doc: Consistently back-quote
- Documentation: 'git add -A' can remove files
I didn't like the existing documentation for "add -u" myself (especially
because I wrote the initial version) and this neatly fix it as well.
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- 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.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* 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 2009-12-29 at c89a730)
+ 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
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
- Document date formats accepted by parse_date()
- builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- 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
* 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.
* mo/bin-wrappers (2009-12-02) 3 commits
- INSTALL: document a simpler way to run uninstalled builds
- run test suite without dashed git-commands in PATH
- build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-28) 4 commits
(merged to 'next' on 2009-12-30 at e143bc9)
+ Remove http.authAny
(merged to 'next' on 2009-12-07 at f08d447)
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-30) 23 commits
(merged to 'next' on 2009-12-31 at 442ff22)
+ grep: do not do external grep on skip-worktree entries
(merged to 'next' on 2009-12-24 at 1fa9ff3)
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
(merged to 'next' on 2009-11-25 at 71380f5)
+ tests: rename duplicate t1009
(merged to 'next' on 2009-11-23 at f712a41)
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
--------------------------------------------------
[Ejected]
* il/exec-error-report (2009-12-30) 2 commits
. Improve transport helper exec failure reporting
. Report exec errors from run-command
Freezes "git log" or anything that uses pager; J6t made quite a many good
suggestions. Expecting more rounds of reroll.
* je/send-email-no-subject (2009-08-05) 1 commit
(merged to 'next' on 2009-10-11 at 1b99c56)
+ send-email: confirm on empty mail subjects
* jc/fix-tree-walk (2009-10-22) 8 commits
(merged to 'next' on 2009-10-22 at 10c0c8f)
+ Revert failed attempt since 353c5ee
+ read-tree --debug-unpack
(merged to 'next' on 2009-10-11 at 0b058e2)
+ 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
This has some stupid bugs and reverted from 'next' until I can fix it, but
the "temporarily" turned out to be very loooong.
* jc/grep-full-tree (2009-11-24) 1 commit
. grep: --full-tree
The interaction with this option and pathspecs need to be worked out
better. I _think_ "grep --full-tree -e pattern -- '*.h'" should find from
all the header files in the tree, for example.
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2010-01-01 0:09 UTC (permalink / raw)
To: git
Welcome to git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* IRC and Mailing list
Members of the development community can sometimes be found on #git
IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
The development is primarily done on the Git mailing list If you have
patches, please send them to the list address (git@vger.kernel.org).
following Documentation/SubmittingPatches. You don't have to be
subscribed to send messages there, and the convention is to Cc:
everybody involved, so you don't even have to say "Please Cc: me, I am
not subscribed".
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting, but
it also is possible that it was simply lost in the noise. Please do not
hesitate to send a reminder message politely in such a case. Messages
getting lost in the noise is a sign that people involved don't have enough
mental/time bandwidth to process them right at the moment, and it often
helps to wait until the list traffic becomes calmer before sending such a
reminder.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as
gmane newsgroup to "jump to" the article.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
Immediately after I publish to the primary repository at kernel.org, I
also push into an alternate here:
git://repo.or.cz/alt-git.git/
Impatient people might have better luck with the latter one.
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "todo", "html" and "man". The first one was meant to
contain TODO list for me, but I am not good at maintaining such a list and
it is in an abandoned state. The branch mostly is used to keep some
helper scripts I use to maintain git and the regular "What's cooking"
messages these days.
The "html" and "man" are autogenerated documentation from the tip of the
"master" branch; the tip of "html" is extracted to be visible at
kernel.org at:
http://www.kernel.org/pub/software/scm/git/docs/
The above URL is the top-level documentation page, and it has
links to documentation of older releases.
The script to maintain these two documentation branches are found in the
"todo" branch as dodoc.sh, if you are interested. It is a demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu". I may add more maintenance
branches (e.g. "maint-1.6.3") if we have hugely backward incompatible
feature updates in the future to keep an older release alive; I may not,
but the distributed nature of git means any volunteer can run a
stable-tree like that herself.
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. There could occasionally be
minor breakages or brown paper bag bugs but they are not expected to be
anything major, and more importantly quickly and trivially fixable. Every
now and then, a "feature release" is cut from the tip of this branch and
they typically are named with three dotted decimal digits. The last such
release was 1.6.6 done on Dec 23rd 2009. You can expect that the tip of
the "master" branch is always more stable than any of the released
versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.6.5.7. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A trivial and safe enhancement goes directly on top of "master". A new
development, either initiated by myself or more often by somebody who
found his or her own itch to scratch, does not usually happen on "master",
however. Instead, a separate topic branch is forked from the tip of
"master", and it first is tested in isolation; I may make minimum fixups
at this point. Usually there are a handful such topic branches that are
running ahead of "master" in git.git repository. I do not publish the tip
of these branches in my public repository, however, partly to keep the
number of branches that downstream developers need to worry about low, and
primarily because I am lazy.
The quality of topic branches are judged primarily by the mailing list
discussions. Some of them start out as "good idea but obviously is broken
in some areas (e.g. breaks the existing testsuite)" and then with some
more work (either by the original contributor's effort or help from other
people on the list) becomes "more or less done and can now be tested by
wider audience". Luckily, most of them start out in the latter, better
shape.
The "next" branch is to merge and test topic branches in the latter
category. In general, the branch always contains the tip of "master". It
might not be quite rock-solid production ready, but is expected to work
more or less without major breakage. I usually use "next" version of git
for my own work, so it cannot be _that_ broken to prevent me from
integrating and pushing the changes out. The "next" branch is where new
and exciting things take place.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either (this automatically means the topics that have
been merged into "next" are usually not rebased, and you can find the tip
of topic branches you are interested in from the output of "git log
next"). You should be able to safely build on top of them.
After a feature release is made from "master", however, "next" will be
rebuilt from the tip of "master" using the surviving topics. The commit
that replaces the tip of the "next" will usually have the identical tree,
but it will have different ancestry from the tip of "master".
The "pu" (proposed updates) branch bundles all the remainder of topic
branches. The "pu" branch, and topic branches that are only in "pu", are
subject to rebasing in general. By the above definition of how "next"
works, you can tell that this branch will contain quite experimental and
obviously broken stuff.
When a topic that was in "pu" proves to be in testable shape, it graduates
to "next". I do this with:
git checkout next
git merge that-topic-branch
Sometimes, an idea that looked promising turns out to be not so good and
the topic can be dropped from "pu" in such a case.
A topic that is in "next" is expected to be polished to perfection before
it is merged to "master" (that's why "master" can be expected to stay more
stable than any released version). Similarly to the above, I do it with
this:
git checkout master
git merge that-topic-branch
git branch -d that-topic-branch
Note that being in "next" is not a guarantee to appear in the next release
(being in "master" is such a guarantee, unless it is later found seriously
broken and reverted), nor even in any future release. There even were
cases that topics needed reverting a few commits in them before graduating
to "master", or a topic that already was in "next" were entirely reverted
from "next" because fatal flaws were found in them later.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from Shawn Pearce's git-gui project:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus on general design issues.
- Linus, Shawn Pearce, Johannes Schindelin, Nicolas Pitre, Ren辿
Scharfe, Jeff King and Johannes Sixt on general implementation
issues.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff and Frank Lichtenheld on cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong on git-svn.
- Simon Hausmann on git-p4.
- Jakub Narebski, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields on documentation (and countless others for
proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- Charles Bailey for taking good care of git-mergetool (and Theodore
Ts'o for creating it in the first place).
- David Aguilar for git-difftool.
- Johannes Schindelin, Johannes Sixt and others for their effort to
move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on
portability; especially, Randal Schwartz, Theodore Ts'o, Jason
Riedy, Thomas Glanzmann, Brandon Casey, Jeff King, Alex Riesen and
countless others.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* Re: [PATCH] t9700-perl-git.sh: Fix a test failure on Cygwin
From: Junio C Hamano @ 2010-01-01 0:07 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: GIT Mailing-list
In-Reply-To: <20100101090515.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Junio, could you tell us what happened to this thread?
>>
>> Hmph, I think we have it as 81f4026 (t9700-perl-git.sh: Fix a test failure
>> on Cygwin, 2009-11-19).
>
> Oh, my mistake. I'm very sorry for wasting your time.
That's Ok; your other reminders were all good ones and greatly
appreciated.
But let me slow down. I'll reply to the other messages next year ;-).
^ permalink raw reply
* Re: [PATCH 0/4] Makefile fixes
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jonathan Nieder, git
In-Reply-To: <20091128112546.GA10059@progeny.tock>
Junio, could you tell us what happened to this thread?
Makefile improvements. No discussion.
^ permalink raw reply
* Re: [PATCH/RFC 0/2] Lazily generate header dependencies
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Johannes Sixt, Git Mailing List,
Johannes Schindelin
In-Reply-To: <20091127174558.GA3461@progeny.tock>
Junio, could you tell us what happened to this thread?
Makefile improvements. No discussion.
^ permalink raw reply
* Re: Client-side mirroring patches (v0)
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <1259143617-26580-1-git-send-email-sam@vilain.net>
Junio, could you tell us what happened to this thread?
^ permalink raw reply
* Re: git pull -s subtree doesn't work properly
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
In-Reply-To: <20091231193800.GB19537@cs-wsok.swansea.ac.uk>
Quoting Oliver Kullmann <O.Kullmann@swansea.ac.uk>
> it seems no reply yet (if I understand that web-email-interface
> properly); has nobody any idea here, or is it a Git bug,
> or my fault?
Because you don't specify where in your current directory hierarchy the root level of the tree you are merging goes when you run "git merge -s subtree", the merge mechanism has to find the most similar directory by itself, and if you have more than one similar directories, it can't guess correctly.
It sounds similar to
http://thread.gmane.org/gmane.comp.version-control.git/135009/focus=135033
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] t9700-perl-git.sh: Fix a test failure on Cygwin
From: Nanako Shiraishi @ 2010-01-01 0:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Ramsay Jones, GIT Mailing-list
In-Reply-To: <7vbphfzlgt.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> Junio, could you tell us what happened to this thread?
>
> Hmph, I think we have it as 81f4026 (t9700-perl-git.sh: Fix a test failure
> on Cygwin, 2009-11-19).
Oh, my mistake. I'm very sorry for wasting your time.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Provide a window icon on Windows platforms
From: Pat Thoyts @ 2009-12-31 23:47 UTC (permalink / raw)
To: Kirill; +Cc: git, msysgit
In-Reply-To: <000701ca8a6a$7c002070$74006150$@com>
2009/12/31 Kirill <kirillathome@gmail.com>:
> Unfortunately, I have to insist on my patch :)
>
>> -----Original Message-----
>> From: Pat Thoyts [mailto:patthoyts@googlemail.com]
>> Sent: Thursday, December 31, 2009 4:12 PM
>
>> 2009/12/31 Kirill <kirillathome@gmail.com>:
>> > Looks like 37871b73 by Giuseppe Bilotta does not work very well on
>> > Windows. Instead of a former tcl/tk icon, the window has a black
>> > square as an icon.
>>
>> I've been using versions of gitk on Windows with that patch since it
>> was applied in March and it has been fine. On Windows XP and Windows
>> 7. So there is more to this than you are telling. Are you using
>> windows via remote desktop?
> You're absolutely right about *unintentional* withdrawal of facts in my original message, but no, I'm not using Remote Desktop. However, my XP SP3 has 16-bit colors and apparently 8.5.7 can't display those photos correctly in this case either. Most probable reason why the issue was first discovered in Remote Desktop is because most of RDP sessions are limited to 16-bit colors.
>
>> If so, this requires an updated Tk and not a patch to gitk -
>> tk 8.5.8 should be ok if this is the problem.
> Unfortunately, the situation is improved with 8.5.8, but definitely not resolved (tested on msysGit devel branch). The sequence image create photo && wm iconphoto on 16-bit displays in XP SP3 renders the background black, not transparent. The fact that I'm using Classic color schema may play some role too. I'd speculate that 8.5.8 on Windows 7 (admittedly, it's much harder to switch to 16-bit colors there) may have exactly the same issue, given that 8.5.7 has exactly the same symptoms.
No - it will be the use of 16bit color. Classic gets used a lot, 16
bit colour - well, you might be the only one now so such a system has
limited testing.
>
> Is there a way to replace the "simplistic"
>
> if {$::tcl_platform(platform) eq {windows}}
>
> with something more elaborate that takes into account 16-bit colors?
That is better done using 'if {[tk windowingsystem] eq "win32"}
{...}'. The windowingsystem command is preferred over platform because
they are not always equivalent (for instance, MacOSX may use either
x11 or aqua).
To test the colour-depth there is [winfo depth .] which returns 16
when using the 16bit color on XP and 32 on Win7 with full color.
Pat Thoyts
^ permalink raw reply
* Re: [PATCH] branch: die explicitly why when calling "git branch [-a|-r] branchname".
From: Junio C Hamano @ 2009-12-31 23:09 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1262184331-9102-1-git-send-email-Matthieu.Moy@imag.fr>
Thanks; will apply to 'maint', together with the SubmittingPatches
addition.
Interestingly, this revealed a long-standing breakage in t5403.
^ permalink raw reply
* Re: [PATCH] fast-import: Document author/committer/tagger name is optional
From: Junio C Hamano @ 2009-12-31 23:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: David Reiss, git@vger.kernel.org
In-Reply-To: <20091230150348.GF6914@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> David Reiss <dreiss@facebook.com> wrote:
> > >> author <somename> 1261454209 +0000
> > >> committer <somename> 1261454209 +0000
> > > a foreign system where the data might not reasonably exist.
> > But shouldn't there still be an extra space? One to separate "author"
> > from the empty name, and one to separate the empty name from the email?
> > If not, then I think this change should be made. (I couldn't find any
> > authoritative documentation on what constitutes a valid commit object.)
>
> Yes, we should do this.
Thanks.
^ permalink raw reply
* RE: [PATCH] Provide a window icon on Windows platforms
From: Kirill @ 2009-12-31 22:42 UTC (permalink / raw)
To: 'Pat Thoyts'; +Cc: git, msysgit
In-Reply-To: <a5b261830912311312if3d71aax5bb693a907dc5c0f@mail.gmail.com>
Unfortunately, I have to insist on my patch :)
> -----Original Message-----
> From: Pat Thoyts [mailto:patthoyts@googlemail.com]
> Sent: Thursday, December 31, 2009 4:12 PM
> 2009/12/31 Kirill <kirillathome@gmail.com>:
> > Looks like 37871b73 by Giuseppe Bilotta does not work very well on
> > Windows. Instead of a former tcl/tk icon, the window has a black
> > square as an icon.
>
> I've been using versions of gitk on Windows with that patch since it
> was applied in March and it has been fine. On Windows XP and Windows
> 7. So there is more to this than you are telling. Are you using
> windows via remote desktop?
You're absolutely right about *unintentional* withdrawal of facts in my original message, but no, I'm not using Remote Desktop. However, my XP SP3 has 16-bit colors and apparently 8.5.7 can't display those photos correctly in this case either. Most probable reason why the issue was first discovered in Remote Desktop is because most of RDP sessions are limited to 16-bit colors.
> If so, this requires an updated Tk and not a patch to gitk -
> tk 8.5.8 should be ok if this is the problem.
Unfortunately, the situation is improved with 8.5.8, but definitely not resolved (tested on msysGit devel branch). The sequence image create photo && wm iconphoto on 16-bit displays in XP SP3 renders the background black, not transparent. The fact that I'm using Classic color schema may play some role too. I'd speculate that 8.5.8 on Windows 7 (admittedly, it's much harder to switch to 16-bit colors there) may have exactly the same issue, given that 8.5.7 has exactly the same symptoms.
Is there a way to replace the "simplistic"
if {$::tcl_platform(platform) eq {windows}}
with something more elaborate that takes into account 16-bit colors?
--
Kirill.
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2009-12-31 22:16 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20091231214134.GA31399@coredump.intra.peff.net>
On Donnerstag, 31. Dezember 2009, Jeff King wrote:
> But of course if we use your trick internally in run-command, then your
> pager-specific change can just go away.
This is what I had in mind.
> > It does assume that we are able to detect execvp failure due to
> > ENOENT which is currently proposed elsewhere by Ilari Liusvaara (and
> > which is already possible on Windows).
>
> We could also simply do the path lookup ourselves, decide whether to use
> the shell, and then exec.
I tried to convince Ilari that this is the way to go, but...
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Johannes Sixt @ 2009-12-31 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Nanako Shiraishi, git
In-Reply-To: <7v4on7x6w1.fsf@alter.siamese.dyndns.org>
On Donnerstag, 31. Dezember 2009, Junio C Hamano wrote:
> It is a cute idea that covers 70-80% of the cases, as you also have to
> assume that you don't have to specify your own pager on a path with IFS
> (e.g. "Program files" in your example) and give your parameter to the
> pager at the same time, e.g.
>
> PAGER="C:\Program Files\cygwin\bin\less -FRSX"
>
> Because it has its own LESS environment to set FRSX and you can get away
> with:
>
> PAGER="C:\Program Files\cygwin\bin\less"
> LESS=FRSX
>
> "less" is not a representative example for this issue. In real life I
> suspect that custom programs that we don't ship with git (or you don't
> ship with msysgit) would lack such a workaround, (and that is why I didn't
> say "98% of the cases").
OTOH, once you see that you would have to set
PAGER: C:\Program Files\cygwin\bin\less -FRSX
(I'm not using shell syntax here; think of a dialog that has name and value in
separate edit boxes) then it is rather obvious that this cannot work. If you
are clever (and you probably are - after all, you are modifying something
esoteric: the environment!), then you will have heard about the magic
double-quotes, and you will write this as
PAGER: "C:\Program Files\cygwin\bin\less" -FRSX
instead, and it will work as intended.
Granted, "less" is not representative.
GIT_EDITOR: "C:\Program Files\Notepad++\notepad++" -multiInst
is probably more realistic (but I didn't test it).
-- Hannes
^ permalink raw reply
* Re: [PATCH 3/6] run-command: optimize out useless shell calls
From: Jeff King @ 2009-12-31 21:41 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <4B3CD74D.7020605@kdbg.org>
On Thu, Dec 31, 2009 at 05:54:37PM +0100, Johannes Sixt wrote:
> The git version that msysgit ships (and the one that I use on
> Windows) has this sequence in pager.c:
>
> static const char *pager_argv[] = { "sh", "-c", NULL, NULL };
> ...
> pager_process.argv = &pager_argv[2];
> pager_process.in = -1;
> if (start_command(&pager_process)) {
> pager_process.argv = pager_argv;
> pager_process.in = -1;
> if (start_command(&pager_process))
> return;
> }
As a side note to what you are saying, my patch 2/6 will break this. The
"new" way to do it would be:
/* do not set pager_argv[2] specially */
pager_process.in = -1;
if (start_command(&pager_process)) {
pager_process.use_shell = 1;
pager_process.in = -1;
if (start_command(&pager_process))
return;
}
though I am happy to also just revert the pager.c changes and leave it
to handle the shell itself.
But of course if we use your trick internally in run-command, then your
pager-specific change can just go away.
> to help people set
>
> PAGER=C:\Program Files\cygwin\bin\less
>
> That is, we first try to run the program without the shell, then
> retry wrapped in sh -c.
>
> Wouldn't it be possible to do the same here, assuming that we don't
> have programs such as "editor -f" in the path?
Hmm. That is somewhat clever. And it would actually solve the
backward-compatibility problem for helpers moving to shell execution. If
you have a textconv of "/path with space/foo", it will continue to
work transparently, but now "/path_without_space/foo --option" will also
Just Work.
The two downsides I see are:
1. You want to run "foo" with "-bar" in your path but you have "foo
-bar" in your path (your "editor -f" example). This just seems
insane to me.
2. There is a little bit of an interface inconsistency. You can do
PAGER="/path with space/foo", but once you want to add an option,
PAGER="/path with space/foo -bar" does not do what you mean. You
have to understand the magic that is going on, and that you now
need to quote the first part.
I'm not sure that is not a feature, though. You are paying that
cost in the transition, but getting the DWYM magic for the common
case.
> It does assume that we are able to detect execvp failure due to
> ENOENT which is currently proposed elsewhere by Ilari Liusvaara (and
> which is already possible on Windows).
We could also simply do the path lookup ourselves, decide whether to use
the shell, and then exec. Path lookup is not that hard, and I think we
already have mingw compat routines for it anyway.
-Peff
^ permalink raw reply
* suppress fatal pathspec errors from "git add"?
From: aaron smith @ 2009-12-31 21:24 UTC (permalink / raw)
To: git
I'm looking through the add documentation, I don't see a way to
suppress fatal pathspec errors? For example, if I'm adding 5 files,
but one of them is mis-spelled, can I have git just supress the errors
and add the other four?
thanks much!
^ permalink raw reply
* Re: [msysGit] [PATCH] Provide a window icon on Windows platforms
From: Pat Thoyts @ 2009-12-31 21:12 UTC (permalink / raw)
To: Kirill; +Cc: git, msysgit
In-Reply-To: <1262289470-4208-1-git-send-email-kirillathome@gmail.com>
2009/12/31 Kirill <kirillathome@gmail.com>:
> Looks like 37871b73 by Giuseppe Bilotta does not work very well on Windows.
> Instead of a former tcl/tk icon, the window has a black square as an icon.
I've been using versions of gitk on Windows with that patch since it
was applied in March and it has been fine. On Windows XP and Windows
7. So there is more to this than you are telling. Are you using
windows via remote desktop? There was a patch committed to Tk a while
ago about the program icon displaying as a black square over remote
desktop. If so, this requires an updated Tk and not a patch to gitk -
tk 8.5.8 should be ok if this is the problem.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-12-31 20:37 UTC (permalink / raw)
To: David Aguilar
Cc: Nanako Shiraishi, peff, sam, git, paulus, Markus Heidelberg,
Jay Soffian
In-Reply-To: <20091231071642.GA10067@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> I started the first step:
>
> http://thread.gmane.org/gmane.comp.version-control.git/135613
> http://thread.gmane.org/gmane.comp.version-control.git/135613/focus=135612
Thanks.
> The 2nd patch implements the the --gui option which Markus
> pointed out would be needed to avoid issues such as calling
> "vimdiff" from a console-less gitk:
>
> http://article.gmane.org/gmane.comp.version-control.git/133386
>
> I marked the --gui patch as "RFC" since it introduced a new
> config variable and I want to make sure that we agreed on its
> name. I didn't get any feedback about that patch
> (my fault-- we were in RC freeze and I forgot to CC: Markus).
I don't think "diff.guitool" would hurt. However,...
I think the "--gui" patch is a more or less independent issue to "gitk
runs external diff through difftool", because difftool/mergetool already
have a built-in way to auto-guess which backend to use depending on what
its environment looks like (e.g. do we have $DISPLAY etc.).
The "--gui" patch is about giving a more explicit way for the caller to
control that backend picking decision process and it is more like icing
than a prerequisite for the issue. IOW, I think the end result will be
usable by gitk users even if they do not configure "diff.guitool".
^ permalink raw reply
* Re: git pull -s subtree doesn't work properly
From: Oliver Kullmann @ 2009-12-31 20:37 UTC (permalink / raw)
To: git
In-Reply-To: <20091231193800.GB19537@cs-wsok.swansea.ac.uk>
Just adding a bit more information about the apparently
wrong behaviour of "-s subtree":
The question is what is the "subtree"??? Apparently git just
looks for the first matching file it finds (!) --- now there is in repository B
a file index.html, and there is index.html in A (while B is to be
merged into A), and thus git apparently deduces that must be
the "subtree". If this is not a bug ...
Does the repository name belong to what specifies a "subtree"?
As one can see below, the repository name has been changed.
For example when creating a repository a Github, then the name
of the repository is not really under control, and also how
Git treats repositories, it seems that the name of the repository
doesn't matter.
In this case we have in A the directory "CS_M41", while in B it was
"CS_M41_Programs"; then later in Github the name of B was further
changed to "CS-M41-Programming-in-Java". Is this an issue (should it be)?
Oliver
P.S. Would renaming CS_M41 in A to CS-M41-Programming-in-Java changed something?
Or would it make things worse?
I tried it, and it doesn't make any change.
On Thu, Dec 31, 2009 at 07:38:00PM +0000, Oliver Kullmann wrote:
> Hello,
>
> it seems no reply yet (if I understand that web-email-interface
> properly); has nobody any idea here, or is it a Git bug,
> or my fault?
>
> To me it seems all pretty normal, so I would be glad to get
> some reaction.
>
> The situation didn't improve: It seems "subtree" is completely broken ---
> it has no idea that the files to be pulled are to be placed in
> a subtree. (The pull via "git pull -s subtree CSM41 master" actually
> also manages to ignore the ignore-patterns; don't know how this
> could happen.)
>
> So shouldn't one use this option?
> Or how can I restart?
>
> I would also need in other situations the ability of Git to have one independent repository (say,
> at Github), which is also included in some other bigger repository (where it is
> not changed, only included) --- how to do so if the "subtree"-mechanism doesn't work?
>
> Hope for some help.
>
> Oliver
>
>
>
> On Thu, Nov 05, 2009 at 06:09:05PM +0000, Oliver Kullmann wrote:
> > Hello,
> >
> > using
> >
> > IntroductionJava> git remote add -f CSM41 /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> > IntroductionJava> git merge -s ours --no-commit CSM41/master
> > IntroductionJava> git read-tree --prefix=Artikel/Skripte/IntroductionJava/CS_M41/ -u CSM41/master
> > IntroductionJava> git commit -m "Einfuegen des CS-M41-Projektes als Verzeichnis CS_M41"
> >
> > I have imported repository "CS-M41_Programs" into another repository. Later then
> > I replaced in the config-file the old url /home/kullmann/csoliver/UofT/Java0910/ProgrammingJava/CS-M41_Programs
> > by the new one
> >
> > [remote "CSM41"]
> > url = git://github.com/OKullmann/CS-M41-Programming-in-Java.git
> > fetch = +refs/heads/*:refs/remotes/CSM41/*
> >
> > But now
> >
> > IntroductionJava> git pull -s subtree CSM41 master
> >
> > doesn't work anymore: In the CSM41 repository just one file index.html was changed,
> > and apparently the merge strategy recognises that the other files haven't
> > been changed, while index.html is placed just as if the relative path would
> > start from the root of the repository.
> >
> > IntroductionJava> git pull -s subtree CSM41 master
> > remote: Counting objects: 7, done.
> > remote: Compressing objects: 100% (3/3), done.
> > remote: Total 4 (delta 1), reused 0 (delta 0)
> > Unpacking objects: 100% (4/4), done.
> > >From git://github.com/OKullmann/CS-M41-Programming-in-Java
> > * branch master -> FETCH_HEAD
> > CONFLICT (delete/modify): Artikel/LaTeX/SystemStile/Html/index.html deleted in HEAD a
> > nd modified in 38b11a96fa009a5b2c24cfc94c0268ab9ca7ce39. Version 38b11a96fa009a5b2c24
> > cfc94c0268ab9ca7ce39 of Artikel/LaTeX/SystemStile/Html/index.html left in tree.
> > Automatic merge failed; fix conflicts and then commit the result.
> >
> > IntroductionJava> git status
> > # On branch master
> > # Unmerged paths:
> > # (use "git reset HEAD <file>..." to unstage)
> > # (use "git add <file>..." to mark resolution)
> > #
> > # deleted by us: ../../LaTeX/SystemStile/Html/index.html
> > #
> > no changes added to commit (use "git add" and/or "git commit -a")
> >
> > The path of index.html is Artikel/Skripte/IntroductionJava/CS_M41/Html/index.html.
> > Why git thinks that index.html should be placed into another directory Artikel/LaTeX/SystemStile/Html/
> > I have no clue (this directory doesn't exist).
> >
> > Is it possible to tell "git pull" where the subtree really is, or is that
> > not really the cause of the problem?
> >
> > Thanks for your consideration!
> >
> > Oliver
> >
^ permalink raw reply
* Re: [PATCH v2] cvsserver: make the output of 'update' more compatible with cvs.
From: Junio C Hamano @ 2009-12-31 20:14 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nanako Shiraishi, Sergei Organov, git
In-Reply-To: <46a038f90912310720l4b1cbdebs2b85774ae7e33c0e@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> writes:
> On Thu, Dec 31, 2009 at 7:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Well, since I don't use cvsserver myself, but this v2 was done with
>> improvements based on some review suggestions, I was waiting for a
>> response or two from people who know better and care more about cvs server
>> emulation than me, which unfortunately didn't happen.
>
> Looks good to me -- good to get it into pu. While I continue to use
> git extensively, I don't use cvsserver anymore, nor work with people
> that do. Might have reason to revisit cvsserver in the near future
> though, to help Moodle transition to git.
>
> That transition will bring a few top-posters and Eclipse lovers to the
> list. Looking past such details, they are fine people who may need a
> little bit of git-newbie help ;-)
>
> happy new year,
Happy new year to you, Nana and Sergei, but not yet in my timezone ;-)
Thanks; I'll forge/add your "Acked-by:" when I queue it.
^ permalink raw reply
* Re: [PATCH] Provide a window icon on Windows platforms
From: Kirill @ 2009-12-31 20:13 UTC (permalink / raw)
To: Jeff Epler; +Cc: git, msysgit
In-Reply-To: <20091231200240.GC13700@unpythonic.net>
On Thu, Dec 31, 2009 at 3:02 PM, Jeff Epler wrote:
> On Thu, Dec 31, 2009 at 02:57:50PM -0500, Kirill wrote:
>> + set ::tk::AlwaysShowSelection 1
>> +
>> + # Spoof an X11 display for SSH
>> + if {![info exists env(DISPLAY)]} {
>> + set env(DISPLAY) :9999
>> + }
>
> these bits look unrelated and should probably be in a separate
> submission.
The only reason this code is here: Git Gui has it in the same section.
Given my total lack of Tcl/Tk skills and deep understanding, I hoped
to fix some other Windows-specific annoyances "by accident".
If Tcl/Tk gurus, for example, Paul Mackerras, say they're wrong, I'll
gladly remove them. If the only objection is the inclusion into the
same patch, I can do that too.
Thanks for your time!
--
Kirill.
^ 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