* Re: [PATCHv5 00/14] git notes
From: Johan Herland @ 2009-09-08 22:46 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Junio C Hamano, trast, tavestbo, git, chriscool, spearce
In-Reply-To: <alpine.DEB.1.00.0909081741590.4330@intel-tinevez-2-302>
On Tuesday 08 September 2009, Johannes Schindelin wrote:
> On Tue, 8 Sep 2009, Johan Herland wrote:
> > On Tuesday 08 September 2009, Johannes Schindelin wrote:
> > > I can see that some people may think that date-based fan-out is the
> > > cat's ass, but I have to warn that we have no idea how notes will be
> > > used,
> >
> > I don't agree. Although we will certainly see many more use cases for
> > notes, I believe that the vast majority of them can be placed in one of
> > two categories:
>
> My experience with Git is that having beliefs how my work is used was a
> constant source of surprise.
And you believe that a system that only allows SHA1-based fanout schemes is
better equipped to tackle such surprises than a system that provides both
date-based and SHA1-based fanout schemes?
> > > - I find the restriction to commits rather limiting.
> >
> > I see your point, but I don't agree until I see a compelling case for
> > annotating a non-commit.
>
> My point is that it is too late by then, if you don't allow for a
> flexible and still efficient scheme.
As I replied to Junio, we could use the epoch as a "commit date" for tree
and blob objects, thus making them representable in a date-based fanout
scheme (although if there are a signficant number of non-commit notes, the
code should be smart enough to find a better (SHA1-based probably) fanout
scheme for those notes).
> > > - most of the performance difference between the date-based and the
> > > SHA-1 based fan-out looks to me as if the issue was the top-level
> > > tree. Basically, this tree has to be read _every_ time _anybody_
> > > wants to read a note.
> >
> > Not sure what you're trying to say here. The top-level notes tree is
> > read (as in fill_tree_descriptor()) exactly _once_. After that, it is
> > cached by the internal data structure (until free_commit_notes() or
> > end-of-process).
>
> By that reasoning, we do not need any fan-out scheme.
>
> Keep in mind: reading a large tree object takes a long time. That's why
> we started fan-out. Reading a large number of tree objects also takes a
> long time. That's why I propagated flexible fan-out that is only read-in
> on demand.
Not sure where you're going with this. Of course we want to strike an
optimal balance between the size of tree objects and the number of tree
objects. Nobody is arguing about that. Both SHA1-based and (in the most
common cases) date-based schemes can be used to achieve this balance. But
using date-based fanout has the added advantage of providing better
performance (both runtime- and memory-wise) when looking up notes in a
chronological order.
> > > But I think that having a dynamic fan-out that can even put blobs
> > > into the top-level tree (nothing prevents us from doing that, right?)
> >
> > Well, the "flexible" code does add the new requirement that all entries
> > in a notes (sub)tree object must follow the same scheme, i.e. you
> > cannot have:
> >
> > /12/34567890123456789012345678901234567890
> > /2345/678901234567890123456789012345678901
> >
> > but you can have
> >
> > /12/34567890123456789012345678901234567890
> > /23/45/678901234567890123456789012345678901
>
> Umm, why? Is there any good technical reason?
In the date-based parts of notes tree, there are very good reasons for doing
so: The code peeks at the first tree entry in order to determine what kind
of date-based fanout is used in the current tree object. Subsequent entries
(in that tree object) that do not follow the same format are
skipped/ignored.
The SHA1-based fanout code has not changed since the last iteration, so this
extra requirement is not absolutely necessary for the SHA1-based parts of
the notes tree. However, the extra requirement does guarantee that commit
notes have exactly one unique location in the notes tree, and thus relieves
us of having to keep searching for alternative notes locations, and
concatenate the notes found.
> > > The real question for me, therefore, is: what is the optimal way to
> > > strike the balance between size of the tree objects (which we want to
> > > be small, so that unpacking them is fast) and depth of the fan-out
> > > (which we want to be shallow to avoid reading worst-case 39 tree
> > > objects to get at one single note).
> >
> > s/39/19/ (each fanout must use at least 2 chars of the 40-char SHA1)
>
> That is another unnecessary restriction that could cost you dearly. Just
> think what happens if it turns out that the optimal number of tree items
> is closer to 16 than to 255...
The code can easily be rewritten to allow for "odd" fanouts (1/39, 1/1/38,
etc.). Feel free to submit a patch.
I was, however, naive enough to assume that when git.git decided on using
2/38 fanout for its loose objects, then some performance-related thoughts
went into that decision. If there are indications that multiple-of-2-type
fanouts are not optimal, we should probably reconsider.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [StGit PATCH] Add import -p option
From: Karl Wiberg @ 2009-09-08 22:37 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Gustav Hållberg, Git Mailing List
In-Reply-To: <b0943d9e0909081443g47978cb7mee241d74dc52adf7@mail.gmail.com>
On 2009-09-08 22:43:39 +0100, Catalin Marinas wrote:
> This patch renames some of the existing import options and adds the
> -p (--strip) option which allows stripping the leading slashes of
> the diff paths.
Looks good (and the intent is very good). The import test should
probably be augmented with a test case for -pN, though. (And since you
didn't have to change the test in this patch, presumably the two
options you renamed weren't tested either.)
> + if strip:
> + cmd += ['-p', strip]
This test should probably be "if strip != None". It doesn't _really_
matter, technically, since -p0 is the default, but still ...
--
Karl Wiberg, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git.el: Use git-add-file for unmerged files, remove git-resolve-file
From: Junio C Hamano @ 2009-09-08 23:10 UTC (permalink / raw)
To: Martin Nordholts; +Cc: git, Alexandre Julliard
In-Reply-To: <4AA026AC.10907@gmail.com>
Martin Nordholts <enselic@gmail.com> writes:
> Use `git-add-file' to mark unmerged files as resolved in the
> *git-status* buffer to be consistent with git's CLI instructions. Also
> remove `git-resolve-file' to make it clear that that "R" is a now a
> free keybinding.
I do not know all the details of how Emacs keybinding works, but I had an
impression that something-x sequence is triggered if you type something-X
and you do not have an explicit binding for something-X but you do have a
binding for something-x.
IOW, if I only have
(define-key global-map "\C-xc" 'compile)
then both "\C-xc" and "\C-xC" runs "compile", but in addition to the
above if I also have
(define-key global-map "\C-xC" 'grep-find)
then I can invoke these two commands with lower- and upper- case 'c/C'
after control-x.
If people have been relying on the historical behaviour that typing "R"
marked the path resolved (which may internally have been implemented with
whatever way), and if you are removing that binding, wouldn't that now
expose them to whatever happens to be bound to "r"?
And worse, it is bound to git-remove-file. Shouldn't you at least rebind
the "R" to something safer, like beep?
Am I grossly misunderstanding how Emacs keybindings work? Is the
experiment I did in the initial part of the message with the global-map
relying on some "magic" that only appears in global-map, and there is no
problem doing this in the map this patch is about?
> Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
> Acked-by: Alexandre Julliard <julliard@winehq.org>
> ---
> contrib/emacs/git.el | 13 +------------
> 1 files changed, 1 insertions(+), 12 deletions(-)
>
> diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
> index 8c70ad8..214930a 100644
> --- a/contrib/emacs/git.el
> +++ b/contrib/emacs/git.el
> @@ -1046,7 +1046,7 @@ The FILES list must be sorted."
> (defun git-add-file ()
> "Add marked file(s) to the index cache."
> (interactive)
> - (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored))))
> + (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored 'unmerged))))
> ;; FIXME: add support for directories
> (unless files
> (push (file-relative-name (read-file-name "File to add: " nil nil t)) files))
> @@ -1119,15 +1119,6 @@ The FILES list must be sorted."
> (when buffer (with-current-buffer buffer (revert-buffer t t t)))))
> (git-success-message "Reverted" names))))))
>
> -(defun git-resolve-file ()
> - "Resolve conflicts in marked file(s)."
> - (interactive)
> - (let ((files (git-get-filenames (git-marked-files-state 'unmerged))))
> - (when files
> - (when (apply 'git-call-process-display-error "update-index" "--" files)
> - (git-update-status-files files)
> - (git-success-message "Resolved" files)))))
> -
> (defun git-remove-handled ()
> "Remove handled files from the status list."
> (interactive)
> @@ -1556,7 +1547,6 @@ amended version of it."
> (define-key map "P" 'git-prev-unmerged-file)
> (define-key map "q" 'git-status-quit)
> (define-key map "r" 'git-remove-file)
> - (define-key map "R" 'git-resolve-file)
> (define-key map "t" toggle-map)
> (define-key map "T" 'git-toggle-all-marks)
> (define-key map "u" 'git-unmark-file)
> @@ -1598,7 +1588,6 @@ amended version of it."
> ("Merge"
> ["Next Unmerged File" git-next-unmerged-file t]
> ["Prev Unmerged File" git-prev-unmerged-file t]
> - ["Mark as Resolved" git-resolve-file t]
> ["Interactive Merge File" git-find-file-imerge t]
> ["Diff Against Common Base File" git-diff-file-base t]
> ["Diff Combined" git-diff-file-combined t]
> --
> 1.6.2.5
^ permalink raw reply
* Re: tracking branch for a rebase
From: Julian Phillips @ 2009-09-08 23:17 UTC (permalink / raw)
To: Michael J Gruber
Cc: Johannes Schindelin, Jeff King, Junio C Hamano,
Björn Steinbrink, Pete Wyckoff, git
In-Reply-To: <4AA4D81A.1030203@drmicha.warpmail.net>
On Mon, 7 Sep 2009, Michael J Gruber wrote:
> Solution needs to be:
> - practical (short, clear)
> - not too brutal (on existing users of legal "exotic" refnames)
> - extensible (for later uses)
How about '/^' and 'ref/^'? Since you can't create a ref ending / ...
--
Julian
---
When you ask a question, do you truly want to know the answer, or are you
merely flaunting your power?
-- DMITRI HARKONNEN, Notes to My Sons
^ permalink raw reply
* Re: [RFC PATCH 2/2] INSTALL: Describe a few knobs from the Makefile
From: Brian Gernhardt @ 2009-09-09 0:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vy6opxjx8.fsf@alter.siamese.dyndns.org>
On Sep 8, 2009, at 4:26 PM, Junio C Hamano wrote:
> [rewrite suggestions snipped]
I'll re-roll this and the other INSTALL patch as per your suggested re-
wordings. I tried to add the minimum needed instead of changing
things, but many of your suggestions make sense. And since I'm in
here anyway, might as well change them.
> Brian Gernhardt <brian@gernhardtsoftware.com> writes:
>> + - "openssl". Unless you specify otherwise (with NO_OPENSSL),
>> + you'll get the SHA1 library from here.
>
> It is not very clear what will be affected by disabling this.
>
> - SHA-1 is not used from OpenSSL, as stated;
> - imap-send won't be able to talk over SSL;
>
> Do we still able to walk https:// URLs? If your cURL library is
> linked
> with gnutls I think we can, but I never tried the combination.
Glancing at http*.[ch], it looks like we depend on curl's ability to
speak https instead of using OpenSSL ourselves.
>> + - "perl" is used for several scripts that are useful, but not
>> + required for git (e.g. "git add -i" and "git difftool"). If you
>> + don't need the *.perl scripts or the library contained in perl/,
>> + then use NO_PERL.
>
> I do not think moving "Perl" this low in the requirement level is
> such a
> good idea, at least for now. I'd suggest movign it back immediately
> after
> POSIX-compliant shell, and would say something like this:
>
> - "Perl" is needed to use some of the features (e.g. preparing a
> partial commit using "git add -i/-p", interacting with svn
> repositories with "git svn"). If you can live without these,
> say NO_PERL.
>
> Maybe they are Ruby, github, and general acceptance by many open
> source
> projects these days, but it used to be that the initial entry points
> to
> git were "git cvsimport" and "git svn" for a surprisingly large
> number of
> people.
I didn't move it this low so much as not move it when I moved the
POSIX shell requirement that we can't live without. Although I use
git-svn on a regular basis, I don't think of it as core, but you're
right that it's one of the main tools for many users. Will move.
~~ Brian
^ permalink raw reply
* Re: [PATCH] Makefile: Add NEEDS_CRYPTO_WITH_SSL
From: Brian Gernhardt @ 2009-09-09 0:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List
In-Reply-To: <7vhbvdyysq.fsf@alter.siamese.dyndns.org>
On Sep 8, 2009, at 4:19 PM, Junio C Hamano wrote:
> The patch makes sense to me, but as the result, depending on platforms
> and configuration, we would use three variations when linking imap-
> send
> with no NO_OPENSSL defined:
>
> * Both -lcrypto -lssl
> * Only -lssl
> * Only -lcrypto
>
> I wonder if we can simplify this in some way (not a 1.6.5 topic).
>
> I am suspecting that the reason we do not say "always both" is because
> depending on the vintage of OpenSSL one or the other is missing?
It just occurred to me that I have a Debian machine to test this on.
I generally don't use my web server for testing, but testing a compile
should be safe enough.
Sure enough, it compiles without this patch. It may be a difference
between the linkers. It appears that ERR_error_string() is in
libcrypto for both OS X and Debian and that libssl.{so,dylib} both
have load commands for libcrypto.{so,dylib}, but OS X ld is pickier
than Debian ld. Odd.
I don't see a scenario where only -lcrypto would be used for imap-
send, actually. That would imply that we're using OpenSSL's SHA-1
algorithm but not using it for IMAPS access. SSL_WITH_CRYPTO is about
needing -lssl when using -lcrypto for SHA-1 while CRYPTO_WITH_SSL is
about needing -lcrypto when using -lssl for SSL.
The only simplification I can think of is to make
NEEDS_CRYPTO_WITH_SSL and NEEDS_SSL_WITH_CRYPTO be the same, so that
it will include both any time it includes either one.
NEEDS_SSL_WITH_CRYPTO is set for UnixWare, SCO_SV, and OS X. I only
have the latter to test with so I don't know if the symmetry is true
for the other two.
~~ Brian
^ permalink raw reply
* [PATCH v2 0/3] INSTALL updates
From: Brian Gernhardt @ 2009-09-09 1:50 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
I'm now up to a three patch series for this minor documentation update.
:-/
The first one simply removes the references to code that no longer exists
in our tree. This paragraph will be changed again in 3/3 so this patch
could be dropped, but I left it since the factual error is a different
issue than the later enhancements.
The second patch mostly reorders the text so that later changes are more
obvious. It does contain the changes Junio suggested regarding shell and
perl, since the old wording is archaic and confusing to new users.
The third contains the additions concerning the Makefile switches. It has
been updated based on Junio's commends.
Brian Gernhardt (3):
INSTALL: Update description of our SHA-1 code
INSTALL: Reorder dependencies, split shell and Perl
INSTALL: Describe dependency knobs from Makefile
INSTALL | 48 +++++++++++++++++++++++++++++++-----------------
1 files changed, 31 insertions(+), 17 deletions(-)
^ permalink raw reply
* [PATCH v2 2/3] INSTALL: Reorder dependencies, split shell and Perl
From: Brian Gernhardt @ 2009-09-09 1:51 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <1252461061-75840-1-git-send-email-brian@gernhardtsoftware.com>
The most important and non-optional dependencies should go first, so put
them there. While we're moving them, the descriptions for shell and perl
were archaic, referring to "bare-bones Porcelainish scripts" that have
become powerful and essential.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
Split from v1's 2/2 so the changes don't get confused with the re-order.
I kept the shell and perl re-wordings here since they're also somewhat of
a factual error instead of 3/3's additions.
INSTALL | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/INSTALL b/INSTALL
index 5267468..7ab2580 100644
--- a/INSTALL
+++ b/INSTALL
@@ -52,6 +52,15 @@ Issues of note:
- "zlib", the compression library. Git won't build without it.
+ - "ssh" is used to push and pull over the net.
+
+ - A POSIX-compliant shell is required to run many scripts needed
+ for everyday use (e.g. "bisect", "pull").
+
+ - "Perl" is needed to use some of the features (e.g. preparing a
+ partial commit using "git add -i/-p", interacting with svn
+ repositories with "git svn").
+
- "openssl". Unless you specify otherwise, you'll get the SHA1
library from here.
@@ -70,11 +79,6 @@ Issues of note:
- "wish", the Tcl/Tk windowing shell is used in gitk to show the
history graphically, and in git-gui.
- - "ssh" is used to push and pull over the net
-
- - "perl" and POSIX-compliant shells are needed to use most of
- the bare-bones Porcelainish scripts.
-
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
have all the libraries/tools needed, or you may have
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* [PATCH v2 1/3] INSTALL: Update description of our SHA-1 code
From: Brian Gernhardt @ 2009-09-09 1:50 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <1252461061-75840-1-git-send-email-brian@gernhardtsoftware.com>
We haven't had Mozilla's code or an ARM optimized algorithm since
30ae47b. Reword the paragraph to give credit but not authorship to
Mozilla.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
The only change from v1 here is "based on" -> "inspired by".
INSTALL | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/INSTALL b/INSTALL
index ae7f750..5267468 100644
--- a/INSTALL
+++ b/INSTALL
@@ -56,8 +56,8 @@ Issues of note:
library from here.
If you don't have openssl, you can use one of the SHA1 libraries
- that come with git (git includes the one from Mozilla, and has
- its own PowerPC and ARM optimized ones too - see the Makefile).
+ that come with git (git includes one inspired by Mozilla's and a
+ PowerPC optimized one too - see the Makefile).
- libcurl library; git-http-fetch and git-fetch use them. You
might also want the "curl" executable for debugging purposes.
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* [PATCH v2 3/3] INSTALL: Describe dependency knobs from Makefile
From: Brian Gernhardt @ 2009-09-09 1:51 UTC (permalink / raw)
To: Git List; +Cc: Junio C Hamano
In-Reply-To: <1252461061-75840-1-git-send-email-brian@gernhardtsoftware.com>
We said that some of our dependencies were optional, but didn't say
how to turn them off. Add information for that and mention where to
save the options close to the top of the file.
Also, standardize on both using quotes for the names of the dependencies
and tabs for indentation of the list.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
---
This has the most changes since v1, containing re-writes based on Junio's
comments. The paragraph changed in 1/1 gets changed again to include the
Makefile switches and adapt to changes in the previous paragraph.
I dropped the RFC since Junio seemed to appreciate the changes, but I kept
the style changes here separate from the earlier factual changes both
because I prefer to work that way and to allow the others to continue if
discussion needs to continue on this one.
INSTALL | 38 ++++++++++++++++++++++++--------------
1 files changed, 24 insertions(+), 14 deletions(-)
diff --git a/INSTALL b/INSTALL
index 7ab2580..69c97b2 100644
--- a/INSTALL
+++ b/INSTALL
@@ -13,6 +13,10 @@ that uses $prefix, the built results have some paths encoded,
which are derived from $prefix, so "make all; make prefix=/usr
install" would not work.
+There are many options that can be configured in the makefile using either
+command line defines or a config.mak file. These options are documented at
+the beginning of the Makefile.
+
Alternatively you can use autoconf generated ./configure script to
set up install paths (via config.mak.autogen), so you can write instead
@@ -48,7 +52,9 @@ Issues of note:
export GIT_EXEC_PATH PATH GITPERLLIB
- Git is reasonably self-sufficient, but does depend on a few external
- programs and libraries:
+ programs and libraries. Git can be used without most of them by adding
+ the approriate "NO_<LIBRARY>=YesPlease" to the make command line or
+ config.mak file.
- "zlib", the compression library. Git won't build without it.
@@ -59,25 +65,29 @@ Issues of note:
- "Perl" is needed to use some of the features (e.g. preparing a
partial commit using "git add -i/-p", interacting with svn
- repositories with "git svn").
+ repositories with "git svn"). If you can live without these, use
+ NO_PERL.
- - "openssl". Unless you specify otherwise, you'll get the SHA1
- library from here.
+ - "openssl" library is used by git-imap-send to use IMAP over SSL.
+ If you don't need it, use NO_OPENSSL.
- If you don't have openssl, you can use one of the SHA1 libraries
- that come with git (git includes one inspired by Mozilla's and a
- PowerPC optimized one too - see the Makefile).
+ By default, git uses OpenSSL for SHA1 but it will use it's own
+ library (inspired by Mozilla's) with either NO_OPENSSL or
+ BLK_SHA1. Also included is a version optimized for PowerPC
+ (PPC_SHA1).
- - libcurl library; git-http-fetch and git-fetch use them. You
+ - "libcurl" library is used by git-http-fetch and git-fetch. You
might also want the "curl" executable for debugging purposes.
- If you do not use http transfer, you are probably OK if you
- do not have them.
+ If you do not use http:// or https:// repositories, you do not
+ have to have them (use NO_CURL).
- - expat library; git-http-push uses it for remote lock
- management over DAV. Similar to "curl" above, this is optional.
+ - "expat" library; git-http-push uses it for remote lock
+ management over DAV. Similar to "curl" above, this is optional
+ (with NO_EXPAT).
- - "wish", the Tcl/Tk windowing shell is used in gitk to show the
- history graphically, and in git-gui.
+ - "wish", the Tcl/Tk windowing shell is used in gitk to show the
+ history graphically, and in git-gui. If you don't want gitk or
+ git-gui, you can use NO_TCLTK.
- Some platform specific issues are dealt with Makefile rules,
but depending on your specific installation, you may not
--
1.6.4.2.420.g30ecf
^ permalink raw reply related
* Re: [PATCH v2 2/3] INSTALL: Reorder dependencies, split shell and Perl
From: Junio C Hamano @ 2009-09-09 6:01 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Junio C Hamano
In-Reply-To: <1252461061-75840-3-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> The most important and non-optional dependencies should go first, so put
> them there. While we're moving them, the descriptions for shell and perl
> were archaic, referring to "bare-bones Porcelainish scripts" that have
> become powerful and essential.
>
> Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
> ---
>
> Split from v1's 2/2 so the changes don't get confused with the re-order.
>
> I kept the shell and perl re-wordings here since they're also somewhat of
> a factual error instead of 3/3's additions.
>
> INSTALL | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/INSTALL b/INSTALL
> index 5267468..7ab2580 100644
> --- a/INSTALL
> +++ b/INSTALL
> @@ -52,6 +52,15 @@ Issues of note:
>
> - "zlib", the compression library. Git won't build without it.
>
> + - "ssh" is used to push and pull over the net.
> +
> + - A POSIX-compliant shell is required to run many scripts needed
> + for everyday use (e.g. "bisect", "pull").
>
> + - "Perl" is needed to use some of the features (e.g. preparing a
> + partial commit using "git add -i/-p", interacting with svn
> + repositories with "git svn").
> +
This is a very minor point, but should we even make a distinction between
"scripts" vs "features" here? It is a minor detail that "bisect" and
"pull" are implemented as scripts after all. I dunno.
^ permalink raw reply
* Re: [PATCH v2 3/3] INSTALL: Describe dependency knobs from Makefile
From: Junio C Hamano @ 2009-09-09 6:16 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List
In-Reply-To: <1252461061-75840-4-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> +There are many options that can be configured in the makefile using either
> +command line defines or a config.mak file. These options are documented at
> +the beginning of the Makefile.
> +
I did not like calling "make variables" "options", and also it was unclear
what good these "options" are for. How about...
The beginning of the Makefile documents many variables that affect the way
git is built. You can override them either from the command line, or in a
config.mak file.
^ permalink raw reply
* Re: tracking branch for a rebase
From: Jeff King @ 2009-09-09 10:45 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Björn Steinbrink, Michael J Gruber,
Pete Wyckoff, git
In-Reply-To: <alpine.DEB.1.00.0909071126040.8306@pacific.mpi-cbg.de>
On Mon, Sep 07, 2009 at 11:29:50AM +0200, Johannes Schindelin wrote:
> > I think using @{} is a reasonable extension format.
>
> Sorry to enter this thread that late, but I did not realize that it
> touches my %<branch> work.
>
> Your proposal leads to something like "master@{upstream}@{2.days.ago}",
> which looks ugly. And it is much more to type.
>
> I still think that it is not too-much asked for to require the
> "refs/heads/" prefix if somebody starts her branch names with "%".
I don't have a problem with restricting branch names starting with "%".
However, I do think "%.." is a bit ugly to read. And I am somewhat
concerned that we are eating the last reasonable available
meta-character for this feature, which will make things even harder next
time somebody suggests a clever feature. Which is why the discussion
turned to a generic extension syntax.
I wonder if it is worth adding @{upstream} now, which is fairly safe,
letting it cook for a while, and then adding a "%" alias later after the
concept has proved itself (and people say "I like this feature, but it
really is too much to type").
-Peff
^ permalink raw reply
* Re: [PATCH 3/4] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 11:22 UTC (permalink / raw)
To: Uri Okrent
Cc: Matthieu Moy, Nanako Shiraishi, Junio C Hamano, Teemu Likonen,
Git
In-Reply-To: <4AA6A7A9.3080908@gmail.com>
On Tue, Sep 08, 2009 at 11:51:21AM -0700, Uri Okrent wrote:
> I know that by default I'd like to see new messages, and in case I'm
> doing something adventurous I'd like to see a message I may not have
> seen before. If I had turned off all messages because I got sick of
> seeing one or two in particular, then I'd never know.
Yeah, I think the 'advice.all' option, while clever, is not really
helping anyone. In my revised series, I am just omitting entirely (but
the code is still structured that adding it later would be very easy if
we change our minds).
> P.S. I never really introduced myself to the list... Uri Okrent here
> from L.A. Keep up the great work everyone!
Welcome. :)
-Peff
^ permalink raw reply
* [PATCH 0/2] configurable advice messages
From: Jeff King @ 2009-09-09 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090906072322.GA29949@coredump.intra.peff.net>
On Sun, Sep 06, 2009 at 03:23:22AM -0400, Jeff King wrote:
> I'll re-roll 3 and 4 based on that, but I will wait a bit to see any
> more comments. Probably you should consider patches 1 and 2 as a
> potential series for 'maint', and 3 and 4 should be spun off into their
> own series (they really only rely textually on the first two).
Looks like you applied 1 and 2 already, so here is the re-roll of the
latter two patches incorporating the changes that have been discussed.
[1/2]: push: make non-fast-forward help message configurable
[2/2]: status: make "how to stage" messages optional
-Peff
^ permalink raw reply
* [PATCH 1/2] push: make non-fast-forward help message configurable
From: Jeff King @ 2009-09-09 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909112623.GA30765@coredump.intra.peff.net>
This message is designed to help new users understand what
has happened when refs fail to push. However, it does not
help experienced users at all, and significantly clutters
the output, frequently dwarfing the regular status table and
making it harder to see.
This patch introduces a general configuration mechanism for
optional messages, with this push message as the first
example.
Signed-off-by: Jeff King <peff@peff.net>
---
Changes from the original version:
- s/message/advice/ in the config and filenames.
- no more advice.all config option. The point of this is to shut up
messages that annoy you; It's probably best to let users see a
message, dislike it, and then turn it off manually after making a
decision that they don't need or want to see it. But adding a "never
show me any advice" option means they will never see some of the
messages, which might otherwise be helpful.
My thinking here is influenced by the fact that we are usually pretty
conservative about adding messages in the first place. If we suddenly
had a period of adding a bunch of "you are clueless, and here is how
git works" messages, enabled by default, then I might reconsider.
- I re-worked the code to give each preference its own variable. This
means we can avoid maintaining a separate list of "#define
MESSAGE_ONE 1" in addition to the array. It also means that checking
a preference is a little nicer. Instead of:
if (advice[ADVICE_PUSH_NONFASTFORWARD].preference)
you get:
if (advice_push_nonfastforward)
Documentation/config.txt | 11 +++++++++++
Makefile | 2 ++
advice.c | 25 +++++++++++++++++++++++++
advice.h | 8 ++++++++
builtin-push.c | 2 +-
cache.h | 1 +
config.c | 3 +++
7 files changed, 51 insertions(+), 1 deletions(-)
create mode 100644 advice.c
create mode 100644 advice.h
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 5256c7f..a35b918 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -113,6 +113,17 @@ For command-specific variables, you will find a more detailed description
in the appropriate manual page. You will find a description of non-core
porcelain configuration variables in the respective porcelain documentation.
+advice.*::
+ When set to 'true', display the given optional help message.
+ When set to 'false', do not display. The configuration variables
+ are:
++
+--
+ pushNonFastForward::
+ Advice shown when linkgit:git-push[1] refuses
+ non-fast-forward refs. Default: true.
+--
+
core.fileMode::
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT.
diff --git a/Makefile b/Makefile
index a614347..9d9ff45 100644
--- a/Makefile
+++ b/Makefile
@@ -397,6 +397,7 @@ export PERL_PATH
LIB_FILE=libgit.a
XDIFF_LIB=xdiff/lib.a
+LIB_H += advice.h
LIB_H += archive.h
LIB_H += attr.h
LIB_H += blob.h
@@ -454,6 +455,7 @@ LIB_H += utf8.h
LIB_H += wt-status.h
LIB_OBJS += abspath.o
+LIB_OBJS += advice.o
LIB_OBJS += alias.o
LIB_OBJS += alloc.o
LIB_OBJS += archive.o
diff --git a/advice.c b/advice.c
new file mode 100644
index 0000000..b5216a2
--- /dev/null
+++ b/advice.c
@@ -0,0 +1,25 @@
+#include "cache.h"
+
+int advice_push_nonfastforward = 1;
+
+static struct {
+ const char *name;
+ int *preference;
+} advice_config[] = {
+ { "pushnonfastforward", &advice_push_nonfastforward },
+};
+
+int git_default_advice_config(const char *var, const char *value)
+{
+ const char *k = skip_prefix(var, "advice.");
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(advice_config); i++) {
+ if (strcmp(k, advice_config[i].name))
+ continue;
+ *advice_config[i].preference = git_config_bool(var, value);
+ return 0;
+ }
+
+ return 0;
+}
diff --git a/advice.h b/advice.h
new file mode 100644
index 0000000..862bae3
--- /dev/null
+++ b/advice.h
@@ -0,0 +1,8 @@
+#ifndef ADVICE_H
+#define ADVICE_H
+
+extern int advice_push_nonfastforward;
+
+int git_default_advice_config(const char *var, const char *value);
+
+#endif /* ADVICE_H */
diff --git a/builtin-push.c b/builtin-push.c
index 787011f..6eda372 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -157,7 +157,7 @@ static int do_push(const char *repo, int flags)
continue;
error("failed to push some refs to '%s'", url[i]);
- if (nonfastforward) {
+ if (nonfastforward && advice_push_nonfastforward) {
printf("To prevent you from losing history, non-fast-forward updates were rejected\n"
"Merge the remote changes before pushing again. See the 'non-fast forward'\n"
"section of 'git push --help' for details.\n");
diff --git a/cache.h b/cache.h
index 5fad24c..e1ab092 100644
--- a/cache.h
+++ b/cache.h
@@ -4,6 +4,7 @@
#include "git-compat-util.h"
#include "strbuf.h"
#include "hash.h"
+#include "advice.h"
#include SHA1_HEADER
#ifndef git_SHA_CTX
diff --git a/config.c b/config.c
index e87edea..f21530c 100644
--- a/config.c
+++ b/config.c
@@ -627,6 +627,9 @@ int git_default_config(const char *var, const char *value, void *dummy)
if (!prefixcmp(var, "mailmap."))
return git_default_mailmap_config(var, value);
+ if (!prefixcmp(var, "advice."))
+ return git_default_advice_config(var, value);
+
if (!strcmp(var, "pager.color") || !strcmp(var, "color.pager")) {
pager_use_color = git_config_bool(var,value);
return 0;
--
1.6.5.rc0.173.g0bfef
^ permalink raw reply related
* [PATCH 2/2] status: make "how to stage" messages optional
From: Jeff King @ 2009-09-09 11:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Matthieu Moy, Teemu Likonen, git
In-Reply-To: <20090909112623.GA30765@coredump.intra.peff.net>
These messages are nice for new users, but experienced git
users know how to manipulate the index, and these messages
waste a lot of screen real estate.
Signed-off-by: Jeff King <peff@peff.net>
---
Most changes are just from rebasing on the prior patch.
Since advice.statusAdvice was a bit redundant, I switched it to
advice.statusHints. Just advice.status was a bit too vague for my taste,
especially as we might want something like advice.statusCurrentBranch or
something later. statusHints is a little vague, too, so I'm open to
suggestions.
This version retains the "compact" output of the last version. I.e., no
newline between header and files, as there would be with the hints.
Like:
# Changed but not updated:
modified: foo
I tried looking at it both with and without the newline, and didn't feel
strongly. My reasoning was that people turning off the hints are
probably interested in compactness. Suggestions welcome.
Documentation/config.txt | 4 ++++
advice.c | 2 ++
advice.h | 1 +
wt-status.c | 8 ++++++++
4 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a35b918..8cbabe8 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -122,6 +122,10 @@ advice.*::
pushNonFastForward::
Advice shown when linkgit:git-push[1] refuses
non-fast-forward refs. Default: true.
+ statusHints::
+ Directions on how to stage/unstage/add shown in the
+ output of linkgit:git-status[1] and the template shown
+ when writing commit messages. Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index b5216a2..ae4b1e8 100644
--- a/advice.c
+++ b/advice.c
@@ -1,12 +1,14 @@
#include "cache.h"
int advice_push_nonfastforward = 1;
+int advice_status_hints = 1;
static struct {
const char *name;
int *preference;
} advice_config[] = {
{ "pushnonfastforward", &advice_push_nonfastforward },
+ { "statushints", &advice_status_hints },
};
int git_default_advice_config(const char *var, const char *value)
diff --git a/advice.h b/advice.h
index 862bae3..e9df8e0 100644
--- a/advice.h
+++ b/advice.h
@@ -2,6 +2,7 @@
#define ADVICE_H
extern int advice_push_nonfastforward;
+extern int advice_status_hints;
int git_default_advice_config(const char *var, const char *value);
diff --git a/wt-status.c b/wt-status.c
index 85f3fcb..38eb245 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -48,6 +48,8 @@ static void wt_status_print_unmerged_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Unmerged paths:");
+ if (!advice_status_hints)
+ return;
if (!s->is_initial)
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
else
@@ -60,6 +62,8 @@ static void wt_status_print_cached_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changes to be committed:");
+ if (!advice_status_hints)
+ return;
if (!s->is_initial) {
color_fprintf_ln(s->fp, c, "# (use \"git reset %s <file>...\" to unstage)", s->reference);
} else {
@@ -73,6 +77,8 @@ static void wt_status_print_dirty_header(struct wt_status *s,
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Changed but not updated:");
+ if (!advice_status_hints)
+ return;
if (!has_deleted)
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to update what will be committed)");
else
@@ -85,6 +91,8 @@ static void wt_status_print_untracked_header(struct wt_status *s)
{
const char *c = color(WT_STATUS_HEADER, s);
color_fprintf_ln(s->fp, c, "# Untracked files:");
+ if (!advice_status_hints)
+ return;
color_fprintf_ln(s->fp, c, "# (use \"git add <file>...\" to include in what will be committed)");
color_fprintf_ln(s->fp, c, "#");
}
--
1.6.5.rc0.173.g0bfef
^ permalink raw reply related
* jk/1.7.0-status, was: What's cooking in git.git (Sep 2009, #02; Mon, 07)
From: Jeff King @ 2009-09-09 11:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtyzexnhm.fsf@alter.siamese.dyndns.org>
On Mon, Sep 07, 2009 at 05:56:53PM -0700, Junio C Hamano wrote:
> * jk/1.7.0-status (2009-09-05) 5 commits
> - docs: note that status configuration affects only long format
> (merged to 'next' on 2009-09-07 at 8a7c563)
> + commit: support alternate status formats
> + status: add --porcelain output format
> + status: refactor format option parsing
> + status: refactor short-mode printing to its own function
> (this branch uses jc/1.7.0-status.)
>
> Gives the --short output format to post 1.7.0 "git commit --dry-run" that
> is similar to that of post 1.7.0 "git status".
>
> It might be a good idea to make the --short format part of 1.6.6 without
> waiting for 1.7.0; it would require some branch shuffling to bring the
> short-status patch earlier than the one that makes "status" different from
> "commit --dry-run", though.
It looks like the short-status patch is already right before "commit
--dry-run", but it is of course part of "git stat". So we could get by
with branching from jc/1.7.0-status^, and do one of:
1. develop as if we were a totally separate topic, refactoring, adding
--porcelain mode, etc.
2. just support "--short" from "git status" with as small a change as
possible, and let the rest of the enhancements stay where they are,
for 1.7.0
Option (1) is what I would usually do, but I think in this case it is
just going to end up with me re-doing lots of work as the
almost-duplicated refactoring happening in the two branches is going to
make a gigantic conflict.
And of course option (3) is to just let --short rest until 1.7.0.
-Peff
^ permalink raw reply
* Re: `Git Status`-like output for two local branches
From: Jeff King @ 2009-09-09 12:26 UTC (permalink / raw)
To: demerphq; +Cc: Sverre Rabbelier, Tim Visher, Git Mailing List
In-Reply-To: <9b18b3110909050758k597f917fn3baefa5fdb4741a0@mail.gmail.com>
On Sat, Sep 05, 2009 at 04:58:36PM +0200, demerphq wrote:
> It would be useful in for instance prompt status line. At $work we
> have a number of people using a prompt that includes the result of
> parsing git-status, but something --left-right-count would be much
> nicer, and if i understand it, more efficient (although maybe im
> wrong). In the prompt they use a number of different unicode arrows to
> show what has happened, with a Y type thing for diverged.
Well, if they are using the other bits of "git status" then it may not
be that inefficient compared to a "--left-right-count".
However, it sounds like they are not actually interested in the count,
but just the two bits of information: is A ahead of B, and is B ahead of
A (and then displaying one of four symbols as a result).
And getting that information is even more efficient than just a count,
because you don't have to traverse all of the commits. Though you do
still have to find the merge base, so I'm not sure how much you would be
saving in practice.
A "--left-right-count" does feel like an odd option to "git log" or "git
rev-list", as you are no longer logging or listing anything. In a way,
it makes more sense to me as a special output format of "git
merge-base".
Anyway, I think your example sounds like a reasonable application.
Personally, I do not use a git-enhanced prompt, so it is not my itch to
scratch (and I think a plumbing patch would only make sense if it was a
stepping stone to an actual application, which means somebody needs to
write the actual application).
-Peff
^ permalink raw reply
* Re: Issue 323 in msysgit: Can't clone over http
From: Tay Ray Chuan @ 2009-09-09 12:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, msysgit, Tom Preston-Werner, Jakub Narebski
In-Reply-To: <be6fef0d0909080610j89c0a4bkf1cb0119b9b11db@mail.gmail.com>
Hi,
On Tue, Sep 8, 2009 at 9:10 PM, Tay Ray Chuan <rctay89@gmail.com> wrote:
> On Tue, Sep 8, 2009 at 3:06 AM, Junio C Hamano<gitster@pobox.com> wrote:
>> I am torn about this.
>>
>> On one hand, if we are going to treat such a half failure as nothing
>> conclusive, I do not see a point to keep that check to begin with.
>>
>> On the other hand, if a HEAD request to a URL results in an unauthorized,
>> what plausible excuse the server operator could give for allowing a GET
>> request to the same URL? If we are going to keep the check if *.pack that
>> corresponds to the *.idx will be available, shouldn't we trust whatever
>> check we perform?
>
> I am in favour or removing this check, not just due to its
> unreliability, but for the sake of consistency (we very rarely send a
> HEAD request to poll data before doing a GET).
my patch below is in response to earlier deliberation.
I still think github.com should look into this issue (of differing
responses for HEAD and GET requests).
-- >8 --
Subject: [PATCH] http.c: remove verification of remote packs
Make http.c::fetch_pack_index() no longer check for the remote pack
with a HEAD request before fetching the corresponding pack index file.
Not only does sending a HEAD request before we do a GET incur a
performance penalty, it does not offer any significant error-
prevention advantages (pack fetching in the *_http_pack_request()
methods is capable of handling any errors on its own).
This addresses an issue raised elsewhere:
http://code.google.com/p/msysgit/issues/detail?id=323
http://support.github.com/discussions/repos/957-cant-clone-over-http-or-git
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Junio, I'm not sure if the credits and references ("This addresses...")
should be included, since the patch doesn't look like it's fixing any
thing, even though it is a response to an acknowledged issue.
Please remove those lines if you so wish.
http.c | 11 -----------
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/http.c b/http.c
index 5926c5b..84def9f 100644
--- a/http.c
+++ b/http.c
@@ -869,17 +869,6 @@ static int fetch_pack_index(unsigned char *sha1, const char *base_url)
char *url;
struct strbuf buf = STRBUF_INIT;
- /* Don't use the index if the pack isn't there */
- end_url_with_slash(&buf, base_url);
- strbuf_addf(&buf, "objects/pack/pack-%s.pack", hex);
- url = strbuf_detach(&buf, 0);
-
- if (http_get_strbuf(url, NULL, 0)) {
- ret = error("Unable to verify pack %s is available",
- hex);
- goto cleanup;
- }
-
if (has_pack_index(sha1)) {
ret = 0;
goto cleanup;
--
1.6.4.2
^ permalink raw reply related
* Problem with "dashless options"
From: Henrik Tidefelt @ 2009-09-09 13:21 UTC (permalink / raw)
To: git
Hi,
Yesterday I installed a fresh git (1.6.4.2) on my system using
MacPorts. Some of the git sub-commands work fine (for instance,
checkout, status, remote), while push gives an error as follows:
$ git push isy next
fatal: BUG: dashless options don't support arguments
The same thing happens when I do
$ git push --repo=isy next
Since this seems to be a rather severe problem, I suppose it is that
it is related to the old and perhaps unusual platform I am using. It
is a PowerPC machine running Mac OS 10.4, with GCC powerpc-apple-
darwin8-gcc-4.0.1 and MacPorts 1.8.0.
I'll be happy to provide additional information that might help.
Best regards,
Henrik Tidefelt
^ permalink raw reply
* Re: Problem with "dashless options"
From: Jeff King @ 2009-09-09 14:34 UTC (permalink / raw)
To: Henrik Tidefelt; +Cc: git
In-Reply-To: <D69FA890-4249-4DC9-B8AE-C9F105F1AD3B@isy.liu.se>
On Wed, Sep 09, 2009 at 03:21:30PM +0200, Henrik Tidefelt wrote:
> Yesterday I installed a fresh git (1.6.4.2) on my system using
> MacPorts. Some of the git sub-commands work fine (for instance,
> checkout, status, remote), while push gives an error as follows:
>
> $ git push isy next
> fatal: BUG: dashless options don't support arguments
Hmm. Very strange. The only code path that triggers this is an option
declared with PARSE_OPT_NODASH but not PARSE_OPT_NOARG. But there are
only two options in all of git that use PARSE_OPT_NODASH, and:
1. They are in git grep, not git push.
2. They correctly have PARSE_OPT_NOARG set.
Which leads me to believe that something is writing random cruft on top
of the options struct. Either a stack overflow, or some issue related to
your compiler (either a bug in the compiler, or something non-portable
we are doing).
Can you try applying the patch below which will at least give us a bit
more information about the offending option?
Also, does 1.6.4.1 work OK? Or any other earlier version? If so, can you
try bisecting?
diff --git a/parse-options.c b/parse-options.c
index f7ce523..e93eb67 100644
--- a/parse-options.c
+++ b/parse-options.c
@@ -275,7 +275,15 @@ static int parse_nodash_opt(struct parse_opt_ctx_t *p, const char *arg,
continue;
if ((options->flags & PARSE_OPT_OPTARG) ||
!(options->flags & PARSE_OPT_NOARG))
- die("BUG: dashless options don't support arguments");
+ die("BUG: dashless options don't support arguments\n"
+ "buggy option is:\n"
+ " type: %d\n"
+ " short_name: %c\n"
+ " long_name: %s\n"
+ " flags: %d\n",
+ options->type, options->short_name,
+ options->long_name, options->flags
+ );
if (!(options->flags & PARSE_OPT_NONEG))
die("BUG: dashless options don't support negation");
if (options->long_name)
^ permalink raw reply related
* Funktion like "last commit time" in SVN
From: Benjamin.Glasebach @ 2009-09-09 14:40 UTC (permalink / raw)
To: git
Hello,
does GIT have any Funktion "last commit time" like in SVN?
So that the create and change-time don't change.
Thanks
EISENMANN Anlagenbau GmbH & Co. KG
i.A. Benjamin Glasebach
Postfach 1280 - 71002 Böblingen
Tübinger Straße 81 - 71032 Böblingen
Tel.: +49 7031 78-1632
Fax.: +49 7031 78-22 1632
E-Mail: Benjamin.Glasebach@eisenmann.com
Internet: http://www.eisenmann.com
_________________________________________________________________________
Sitz: Böblingen, AG Stuttgart HRA 241890
USt.-IdNr.: DE 145 141 525
Persönlich haftende Gesellschafterin: EISENMANN Anlagenbau Verwaltung GmbH;
Sitz: Böblingen, AG Stuttgart HRB 245853
Geschäftsführer: Dr. Matthias von Krauland, Dr. Thomas Beck, Dr. Kersten
Christoph Link, Werner Schuster, Ralf Völlinger
Diese E-Mail sowie etwaige Anlagen sind ausschließlich für den Adressaten
bestimmt und können vertrauliche oder gesetzlich geschützte Informationen
enthalten. Wenn Sie nicht der bestimmungsgemäße Empfänger sind,
unterrichten Sie bitte den Absender und vernichten Sie diese Mail.
Anderen als dem bestimmungsgemäßen Adressaten ist es untersagt, diese
E-Mail zu speichern, weiterzuleiten oder ihren Inhalt, auf welche Weise
auch immer, zu verwenden. Wir verwenden aktuelle Virenschutzprogramme.
Für Schäden, die dem Empfänger gleichwohl durch von uns zugesandte, mit
Viren befallene E-Mails entstehen, schließen wir jede Haftung aus.
The information contained in this e-mail or attachments is intended only
for its addressee and may contain confidential and/or privileged
information. If you have received this e-mail in error, please notify
the sender and delete the e-mail. If you are not the intended recipient,
you are hereby notified, that saving, distribution or use of the
content of this e-mail in any way is prohibited. We use updated virus
protection software. We do not accept any responsibility for damages
caused anyhow by viruses transmitted via e-mail.
^ permalink raw reply
* Re: Funktion like "last commit time" in SVN
From: Bruce Stephens @ 2009-09-09 14:53 UTC (permalink / raw)
To: Benjamin.Glasebach; +Cc: git
In-Reply-To: <OFDE6223D3.9B58FBF2-ONC125762C.00502B15-C125762C.005096F0@EISENMANN.DE>
Benjamin.Glasebach@eisenmann.com writes:
> does GIT have any Funktion "last commit time" like in SVN?
> So that the create and change-time don't change.
I don't know exactly what SVN does. Does this help,
<http://git.or.cz/gitwiki/ExampleScripts#Settingthetimestampsofthefilestothecommittimestampofthecommitwhichlasttouchedthem>?
[...]
^ permalink raw reply
* [PATCH] rebase: use plumbing to show dirty state
From: Jeff King @ 2009-09-09 14:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
Commit 4cfbe06 introduced the use of "git diff" to show
dirty state in a format more familiar to users. However, it
should have used the plumbing "git diff-files" instead.
Not only is it good practice in general to use plumbing in
scripts, but in this case we really don't want the automatic
pager to kick in for an error message.
Signed-off-by: Jeff King <peff@peff.net>
---
I got quite a surprise when I ran "git rebase" and was presented with a
pager with nothing but:
M foo.c
in it. I suspect this issue wasn't noticed while testing because most
people use "-FX" with "less", so their short list of dirty files causes
the pager to exit immediately.
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index 2315d95..6ec155c 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -387,7 +387,7 @@ fi
# The tree must be really really clean.
if ! git update-index --ignore-submodules --refresh > /dev/null; then
echo >&2 "cannot rebase: you have unstaged changes"
- git diff --name-status -r --ignore-submodules -- >&2
+ git diff-files --name-status -r --ignore-submodules -- >&2
exit 1
fi
diff=$(git diff-index --cached --name-status -r --ignore-submodules HEAD --)
--
1.6.5.rc0.166.ge65f.dirty
^ permalink raw reply related
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