Re: Our official home page and logo for the Git project
On Fri, Apr 11, 2014 at 3:24 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Moreover, even the black ones have the issue I already mentioned; they picture the equivalent of two root commits (with no parents) that are immediately merged, and the history continues, but who is interested in the initial commits? And who has multiple root commits? No one. [..] My version of the logo is the equivalent of to head commits that diverge from a common one, which is extremely common; everybody works on the latest commits, and has multiple branches. The red logo looks like a merge to me, and a merge with master means 'success' to me. Branching off means new attempts, but they may or may not end up in master. Vincent -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Fwd: [ANNOUNCE] WinGit - native x86/x64 Git for Windows
I know that build.sh is UGLY, especially openssl part. Unlike msysgit, WinGit is a pure-Windows binary build with MSVC. Like msysgit, WinGit also uses msys environment (sh/perl/etc) both during build-time and runtime. WinGit adds a few patches to Git itself on top of msysgit ones. Patches are required due to insufficient testing of MSVC builds (caused by total absence of any MSVC-built Git distributions). I've created CMake files to be able to build git with MSVC without the need for msys. I haven't tested it with latest git and didn't really see the recent changes with respect to compilation with MSVC. But, if you're interested, let me know. Vincent -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gitweb: Avoid overflowing page body frame with large images
On Fri, Feb 7, 2014 at 4:31 AM, Andrew Keller and...@kellerfarm.com wrote: I recently used Git to archive a set of scanned photos, and I used gitweb to provide access to them. Overall, everything worked well, but I found it undesirable that I had to zoom out in my browser on every photo to see the whole photo. In the spirit of making the default behavior the most likely correct behavior, this patch seems to be a good idea. However, I'm not an expert on the use cases of gitweb. In order for the maximum size constraints to take effect, the image would have to be at least the size of the web browser window (minus a handful of pixels), so the affected images are usually going to be pretty big. Are there any common use cases for displaying a large image without scaling (and hence, with scrolling)? Thanks, Andrew It sounds like your usecase is exactly what camlistore.org tries to achieve. Vincent -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Confusing git log --- First time bug submission please advise on best practices
On Thu, Feb 6, 2014 at 3:02 PM, Francis Stephens francissteph...@gmail.com wrote: My co-worker has an inconsistent git log output. Please see that attached files for output (I've made a best effort to remove confidential info from them). Comparing the two log commands we can see that master and originssh/master have a shared common commit at John Doe (4 hours ago) d85832d More pom fixes The top commit for originssh/master and the second to top for master. I would expect that both logs would share an _identical_ history from that commit onward. But the log for master contains the following Jeremy Doe (27 hours ago) 239ea21 (my-work) renamed class Jeremy Doe (28 hours ago) 27750b2 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework and Jeremy Doe (2 days ago) a933acb white space changes Jeremy Doe (2 days ago) b5e51e7 Merge branch 'master' of http://githost.companyname-dev.local/trading-development/sports-container-framework Jeremy Doe (2 days ago) 3a0f787 removed public methods Jeremy Doe (2 days ago) 4e91130 added the xml deserialisation None of which appear in the originssh/master log. Is there a scenario in which this is expected. It was my understanding that any two commits with the same hash have exactly the same history. Thanks for your time. The commits that are in the log for master and which are not in the log for originssh/master are merged in at 6833fd4 (HEAD, master); Completed merge. As git log can only present the commits in a linear way, it shows the commits from the ancentry of both parents of HEAD in a reverse chronological order. This means that the commits from the two ancestries are mixed and commits that are shown after each other don't have to be parent and child. See the documentation of git log and the section Commit Ordering: By default, the commits are shown in reverse chronological order. Vincent -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] build: get rid of the notion of a git library
Op 9-6-2013 17:40, Felipe Contreras schreef:
On Sun, Jun 9, 2013 at 10:12 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 09, 2013 at 08:26:32PM +0530, Ramkumar Ramachandra wrote:
Felipe Contreras wrote:
The plan is simple; make libgit.a a proper library, starting by
clarifying what goes into libgit.a, and what doesn't. If there's any
hopes of ever having a public library, it's clear what code doesn't
belong in libgit.a; code that is meant for builtins, that code belongs
in builtins/lib.a, or similar.
Give this a try:
--- a/sequencer.c
+++ b/sequencer.c
libgit.a(sequencer.o): In function `copy_notes':
/home/felipec/dev/git/sequencer.c:110: undefined reference to
`init_copy_notes_for_rewrite'
/home/felipec/dev/git/sequencer.c:114: undefined reference to
`finish_copy_notes_for_rewrite'
This is a good example: yes, I'm convinced that the code does need to
be reorganized. Please resend your {sequencer.c -
builtin/sequencer.c} patch with this example as the rationale, and
let's work towards improving libgit.a.
Why should sequencer.c move into builtin/ to solve this? Why not pull
init_copy_notes_for_rewrite and finish_copy_notes_for_rewrite up into
notes.c?
Because finish_copy_notes_for_rewrite is only useful for builtin
commands, so it belongs in builtin/. If there's any meaning to the
./*.o vs. builtin/*.o divide, it's for that. Otherwise we should just
squash all objects into libgit.a and be done with it.
I think that libgit.a should contain all code to be able to carry out
all functions of git. The stuff in builtin/ is just a command-line user
interface. Whether or not sequencer should be in builtin depends on
whether the sequencer is only part of this command-line user interface.
I think that the sequencer code is at the moment unusable if you do not
use the code in builtin/ so that would advocate to move it into
builtin/. If sequencer is in libgit, and I write my own (graphical) user
interface, I expect to be able to use it.
Vincent
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
