* [ANNOUNCE] GIT 1.5.2.4
From: Junio C Hamano @ 2007-07-12 20:57 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vodjf1gxl.fsf@assigned-by-dhcp.pobox.com>
The latest maintenance release GIT 1.5.2.4 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.4.tar.{gz,bz2} (tarball)
git-htmldocs-1.5.2.4.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.4.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.2.4-1.$arch.rpm (RPM)
----------------------------------------------------------------
GIT v1.5.2.4 Release Notes
==========================
Fixes since v1.5.2.3
--------------------
* Bugfixes
- "git-gui" bugfixes, including a handful fixes to run it
better on Cygwin/MSYS.
- "git checkout" failed to switch back and forth between
branches, one of which has "frotz -> xyzzy" symlink and
file "xyzzy/filfre", while the other one has a file
"frotz/filfre".
- "git prune" used to segfault upon seeing a commit that is
referred to by a tree object (aka "subproject").
- "git diff --name-status --no-index" mishandled an added file.
- "git apply --reverse --whitespace=warn" still complained
about whitespaces that a forward application would have
introduced.
* Documentation Fixes and Updates
- A handful documentation updates.
----------------------------------------------------------------
Changes since v1.5.2.3 are as follows:
Andy Parkins (2):
Make git-prune submodule aware (and fix a SEGFAULT in the process)
user-manual: grammar and style fixes
Gerrit Pape (1):
git-gui: properly popup error if gitk should be started but is not installed
J. Bruce Fields (2):
tutorial: Fix typo
user-manual: more explanation of push and pull usage
Jim Meyering (1):
Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too long
Johannes Schindelin (3):
diff --no-index: fix --name-status with added files
glossary: add 'reflog'
Fix "apply --reverse" with regard to whitespace
Junio C Hamano (2):
Teach read-tree 2-way merge to ignore intermediate symlinks
GIT 1.5.2.4
Michael Hendricks (1):
Correctly document the name of the global excludes file configuration
Miklos Vajna (1):
Document -<n> for git-format-patch
Shawn O. Pearce (10):
git-gui: Unlock the index when cancelling merge dialog
git-gui: Don't bind F5/M1-R in all windows
git-gui: Bind M1-P to push action
git-gui: Include a Push action on the left toolbar
git-gui: Ensure windows shortcuts always have .bat extension
git-gui: Skip nicknames when selecting author initials
git-gui: Correct ls-tree buffering problem in browser
git-gui: Don't linewrap within console windows
Clarify documentation of fast-import's D subcommand
git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
William Pursell (1):
user-manual: fix directory name in git-archive example
^ permalink raw reply
* Re: git .pack expansion question
From: Brian Gernhardt @ 2007-07-12 20:58 UTC (permalink / raw)
To: Ryan Moszynski; +Cc: git
In-Reply-To: <5ed683f50707121203q52084b72o106616f1c8710141@mail.gmail.com>
On Jul 12, 2007, at 3:03 PM, Ryan Moszynski wrote:
> hopefully this is the right list for this:
>
> am i understanding this right?
>
> if i run the command:
> git-repack
> this creates an .idx and a .pack file that together hold all the files
> and other metadata for my git directory.
You're not understanding it correctly. The .pack files hold all the
data from the git repository, but none of the metadata. The .idx
file is an index into the pack for speed and can be re-created from
the pack itself.
What you're looking for is git-bundle (added just after v1.5.0 it
looks like). `git bundle create <file-name> --all` will bundle up
all the branches from your repository. It doesn't seem to want to
take the tags when I do it that way, but it's definitely the right
start.
~~ Brian
^ permalink raw reply
* Re: Better handling of local changes in 'gitk'?
From: Linus Torvalds @ 2007-07-12 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <7vejjdtkl0.fsf@assigned-by-dhcp.cox.net>
On Thu, 12 Jul 2007, Junio C Hamano wrote:
>
> I just meant that I agree with you that --cc between HEAD, index and the
> working tree is a wonderful way to view the current state.
Heh. I wasn't thinking of --cc, and if seen as a combination diff, I think
--combined would be better (we very much want to see *all* changes, not
just the conflicting ones, no?).
I was literally meaning two separate diffs, as two separate commits. But
yes, I do agree that it might be very interesting to make "git diff-index"
know about --combined/--cc in addition to --cached.
> It might make sense to teach "git diff" itself to show this
> 3-way diff with a new option ("git diff --h-i-w"). The
> necessary machinery is already there to handle "git diff maint
> master next pu" (four trees!), and "git diff maint:Makefile
> master:Makefile next:Makefile" (three blobs).
Actually, I think that if you teach "git diff-index" about --combined and
--cc, then you'll automatically get it when you just do "git diff HEAD".
No?
Linus
^ permalink raw reply
* Re: [PATCH 2/2] Make git-tag a builtin.
From: Carlos Rica @ 2007-07-12 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Kristian Høgsberg
In-Reply-To: <7vps2yxjgq.fsf@assigned-by-dhcp.cox.net>
Thank you for your review, Junio, I'm studing all of your suggestions.
2007/7/12, Junio C Hamano <gitster@pobox.com>:
> Carlos Rica <jasampler@gmail.com> writes:
>
> > Mime-Version: 1.0
> > Content-Type: text/plain; charset=windows-1252
>
> Hmmmmmm.....
> > diff --git a/builtin-tag.c b/builtin-tag.c
> > new file mode 100644
> > index 0000000..1824379
> > --- /dev/null
> > +++ b/builtin-tag.c
> > @@ -0,0 +1,430 @@
> > +/*
> > + * Builtin "git tag"
> > + *
> > + * Copyright (c) 2007 Kristian H??gsberg <krh@redhat.com>,
>
> I do not know how the above would come out, but it surely was
> not Høgsberg in the copy I received...
I think it is my fault. My original builtin-tag.c file has the
name encoded in UTF-8, and the patch too, except because
I also added his name in the commit's message in Latin-1 encoding,
and then, programs cannot recode or recognize both. Sorry.
>
> > + * Carlos Rica <jasampler@gmail.com>
> > + * Based on git-tag.sh and mktag.c by Linus Torvalds.
> > + */
> > +
> > +#include "cache.h"
> > +#include "builtin.h"
> > +#include "refs.h"
> > +#include "tag.h"
> > +#include "run-command.h"
> > +
> > +static const char builtin_tag_usage[] =
> > + "git-tag [-n [<num>]] -l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d | -v] [-m <msg>] <tagname> [<head>]";
> > +
> > +static char signingkey[1000];
> > +static int lines;
> > +
> > +static void launch_editor(const char *path, char **buffer, unsigned long *len)
> > +{
> > + const char *editor, *terminal;
> > + struct child_process child;
> > + const char *args[3];
> > + int fd;
> > +
> > + editor = getenv("VISUAL");
> > + if (!editor)
> > + editor = getenv("EDITOR");
> > +
> > + terminal = getenv("TERM");
> > + if (!editor && (!terminal || !strcmp(terminal, "dumb"))) {
> > + fprintf(stderr,
> > + "Terminal is dumb but no VISUAL nor EDITOR defined.\n"
> > + "Please supply the message using either -m or -F option.\n");
> > + exit(1);
> > + }
>
> Ah, this is taken from git-commit.sh ;-) Does your "git tag"
> support the -F option (builtin_tag_usage[] does not seem to
> mention it)? I wonder what happens when this function migrates
> to editor.c and a new program, other than git-tag and
> git-commit, that is without -F nor -m options wants to call
> this.
I will include that -F option in the builtin_tag_usage and I will also find
if documentation already has it.
As I said above, launch_editor is copied and modified from the builtin-commit.c
that Kristian is currently writing. Indeed, I removed every mention on
it related
specifically to commits, so it will be difficult to share the code between both
versions in the current state. Perhaps a raw function not printing out errors
(and returning error codes instead) could be the only option to reuse it. I need
to ask Kristian for this.
> > +static int run_verify_tag_command(unsigned char *sha1)
> > +{
> > + int ret;
> > + const char *argv_verify_tag[] = {"git-verify-tag",
> > + "-v", "SHA1_HEX", NULL};
> > + argv_verify_tag[2] = sha1_to_hex(sha1);
> > +
> > + ret = run_command_v_opt(argv_verify_tag, 0);
> > +
> > + if (ret <= -10000)
> > + die("unable to run %s\n", argv_verify_tag[0]);
> > + return -ret;
> > +}
>
> I wonder why you need to differentiate between ERR_RUN_COMMAND_*
> and non-zero exit status... Also do you need to "return -ret",
> instead of not negating? In C programs error returns are often
> negative and finish_command() follows that convention.
The point here was to mimic the behaviour of git-tag.sh,
returning the exit status returned by the called script: "git-verify-tag.sh".
However, I didn't realize that git-verify tag.sh was exiting only with 1 or 0,
so "return ret;" will also work since the call to the function is:
if (run_verify_tag_command(sha1))
had_error = 1;
When die is called (because of an ERR_RUN_COMMAND_* error condition),
it will return 128 to the system, and won't do more processing to other tags.
Do yo mean that it would be better to remove this "die" call here?
>
> > + if (!message) {
> > ...
> > + }
> > + else {
> > + buffer = message;
> > + size = strlen(message);
> > + }
> > +
> > + size = stripspace(buffer, size, 1);
> > +
> > + if (!message && !size)
> > + die("no tag message?");
>
> Why check 'message' here?
Because the behaviour of git-tag.sh here is not allow empty
messages when the editor is executed, but allow them when
-m or -F options are given (message then will be not NULL).
> > +int cmd_tag(int argc, const char **argv, const char *prefix)
> > +{
> > ...
> > + if (!strcmp(arg, "-F")) {
> > + unsigned long len;
> > + annotate = 1;
> > + i++;
> > + if (i == argc)
> > + die("option -F needs an argument.");
> > +
> > + fd = open(argv[i], O_RDONLY);
> > + if (fd < 0)
> > + die("cannot open %s", argv[1]);
>
> The shell script version relies on the magic "cat -" to read
> from standard input upon "git tag -F -". It is understandable
> that both of you and Dscho missed it, though.
It should be easy to implement, I will do it.
> > + len = 1024;
> > + message = xmalloc(len);
> > + if (read_pipe(fd, &message, &len))
> > + die("cannot read %s", argv[1]);
> > + message = xrealloc(message, len + 1);
> > + message[len] = '\0';
> > + continue;
> > + }
>
> We might be better off if read_pipe() is renamed to read_fd()
> and made internally always NUL-terminate the buffer (but not
> count that NUL as part of length). I dunno.
I saw an implementation for read_pipe named read_fd from Kristian:
http://article.gmane.org/gmane.comp.version-control.git/51366
but it is only focused on allowing NULL and 0 in pointer and size
parameters. It should be harmless NUL-terminating the buffer
since the routine is already allocating more memory than needed
for efficiency purposes.
^ permalink raw reply
* [PATCH] reduce git-pack-objects memory usage a little more
From: Nicolas Pitre @ 2007-07-12 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
The delta depth doesn't have to be stored in the global object array
structure since it is only used during the deltification pass.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index b4f3e7c..55609f3 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -25,9 +25,6 @@ git-pack-objects [{ -q | --progress | --all-progress }] [--max-pack-size=N] \n\
struct object_entry {
struct pack_idx_entry idx;
unsigned long size; /* uncompressed size */
-
- unsigned int hash; /* name hint hash */
- unsigned int depth; /* delta depth */
struct packed_git *in_pack; /* already in pack */
off_t in_pack_offset;
struct object_entry *delta; /* delta base object */
@@ -37,6 +34,7 @@ struct object_entry {
*/
void *delta_data; /* cached delta (uncompressed) */
unsigned long delta_size; /* delta data size (uncompressed) */
+ unsigned int hash; /* name hint hash */
enum object_type type;
enum object_type in_pack_type; /* could be delta */
unsigned char in_pack_header_size;
@@ -1270,6 +1268,7 @@ struct unpacked {
struct object_entry *entry;
void *data;
struct delta_index *index;
+ unsigned depth;
};
static int delta_cacheable(struct unpacked *trg, struct unpacked *src,
@@ -1328,7 +1327,7 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
return 0;
/* Let's not bust the allowed depth. */
- if (src_entry->depth >= max_depth)
+ if (src->depth >= max_depth)
return 0;
/* Now some size filtering heuristics. */
@@ -1338,9 +1337,9 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
ref_depth = 1;
} else {
max_size = trg_entry->delta_size;
- ref_depth = trg_entry->depth;
+ ref_depth = trg->depth;
}
- max_size = max_size * (max_depth - src_entry->depth) /
+ max_size = max_size * (max_depth - src->depth) /
(max_depth - ref_depth + 1);
if (max_size == 0)
return 0;
@@ -1379,17 +1378,17 @@ static int try_delta(struct unpacked *trg, struct unpacked *src,
if (trg_entry->delta_data) {
/* Prefer only shallower same-sized deltas. */
if (delta_size == trg_entry->delta_size &&
- src_entry->depth + 1 >= trg_entry->depth) {
+ src->depth + 1 >= trg->depth) {
free(delta_buf);
return 0;
}
delta_cache_size -= trg_entry->delta_size;
free(trg_entry->delta_data);
+ trg_entry->delta_data = NULL;
}
- trg_entry->delta_data = 0;
trg_entry->delta = src_entry;
trg_entry->delta_size = delta_size;
- trg_entry->depth = src_entry->depth + 1;
+ trg->depth = src->depth + 1;
if (delta_cacheable(src, trg, src_size, trg_size, delta_size)) {
trg_entry->delta_data = xrealloc(delta_buf, delta_size);
@@ -1484,7 +1483,7 @@ static void find_deltas(struct object_entry **list, int window, int depth)
* depth, leaving it in the window is pointless. we
* should evict it first.
*/
- if (entry->delta && depth <= entry->depth)
+ if (entry->delta && depth <= n->depth)
continue;
next:
^ permalink raw reply related
* Re: pull-fetch-param.txt
From: Junio C Hamano @ 2007-07-12 21:58 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git
In-Reply-To: <20070712130631.13667.qmail@594d46613ccd9b.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> Hi, this still is a problem, at least on Debian/unstable; with asciidoc
> 8.2.1, the git-push(1) and git-fetch(1) man pages have this 'broken'
> refspec description[0].
Quick question. Is the build done with "make
ASCIIDOC8=YesPlease"?
^ permalink raw reply
* [PATCH] Add to gitk an --argscmd flag to get the list of refs to draw at refresh time.
From: Yann Dirson @ 2007-07-12 22:04 UTC (permalink / raw)
To: paulus; +Cc: git
This allows to display a set of refs, when the refs in the set may
themselves change between two refresh operations (eg. the set of
patches in a patch stack), and is expected to be called from other
porcelain suites.
The command is expected to generate a list of commits, which will be
appended to the commits litterally passed on the command-line. That
command is handled similarly to the litteral refs, and has its own
field in the saved view, and an edit field in the view editor.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
This new version causes the command to add its revs to the litteral
ones from command-line instead of overriding them, and allows to
edit the command in the view editor.
Disclaimer: I'm no tcl/tk expert, feel free to flame my style :)
Documentation/gitk.txt | 7 ++++++
gitk | 54 +++++++++++++++++++++++++++++++++++++++++-------
2 files changed, 53 insertions(+), 8 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e9f82b9..71ed8ba 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -41,6 +41,13 @@ frequently used options.
Show all branches.
+--argscmd=<command>::
+ Command to be run each time gitk has to determine the list of
+ <revs> to show. The command is expected to print on its
+ standard output a list of additional revs to be shown. Use
+ this instead of explicitely specifying <revs> if the set of
+ commits to show may vary between refreshs.
+
<revs>::
Limit the revisions to show. This can be either a single revision
diff --git a/gitk b/gitk
index 2d6a6ef..4b6d31b 100755
--- a/gitk
+++ b/gitk
@@ -82,12 +82,22 @@ proc dorunq {} {
proc start_rev_list {view} {
global startmsecs
global commfd leftover tclencoding datemode
- global viewargs viewfiles commitidx
+ global viewargs viewargscmd viewfiles commitidx
global lookingforhead showlocalchanges
set startmsecs [clock clicks -milliseconds]
set commitidx($view) 0
set args $viewargs($view)
+ if {$viewargscmd($view) ne "None"} {
+ if {[catch {
+ set fd [open [concat | $viewargscmd($view)] r]
+ } err]} {
+ puts stderr "Error executing --argscmd command: $err"
+ exit 1
+ }
+ set args [concat $args [read $fd 500000]]
+ close $fd
+ }
if {$viewfiles($view) ne {}} {
set args [concat $args "--" $viewfiles($view)]
}
@@ -943,7 +953,7 @@ proc savestuff {w} {
global canv canv2 canv3 ctext cflist mainfont textfont uifont tabstop
global stuffsaved findmergefiles maxgraphpct
global maxwidth showneartags showlocalchanges
- global viewname viewfiles viewargs viewperm nextviewnum
+ global viewname viewfiles viewargs viewargscmd viewperm nextviewnum
global cmitmode wrapcomment
global colors bgcolor fgcolor diffcolors selectbgcolor
@@ -979,7 +989,7 @@ proc savestuff {w} {
puts -nonewline $f "set permviews {"
for {set v 0} {$v < $nextviewnum} {incr v} {
if {$viewperm($v)} {
- puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v)]}"
+ puts $f "{[list $viewname($v) $viewfiles($v) $viewargs($v) $viewargscmd($v)]}"
}
}
puts $f "}"
@@ -1566,7 +1576,7 @@ proc shellsplit {str} {
proc newview {ishighlight} {
global nextviewnum newviewname newviewperm uifont newishighlight
- global newviewargs revtreeargs
+ global newviewargs revtreeargs viewargscmd newviewargscmd curview
set newishighlight $ishighlight
set top .gitkview
@@ -1577,13 +1587,14 @@ proc newview {ishighlight} {
set newviewname($nextviewnum) "View $nextviewnum"
set newviewperm($nextviewnum) 0
set newviewargs($nextviewnum) [shellarglist $revtreeargs]
+ set newviewargscmd($nextviewnum) [shellarglist $viewargscmd($curview)]
vieweditor $top $nextviewnum "Gitk view definition"
}
proc editview {} {
global curview
global viewname viewperm newviewname newviewperm
- global viewargs newviewargs
+ global viewargs newviewargs viewargscmd newviewargscmd
set top .gitkvedit-$curview
if {[winfo exists $top]} {
@@ -1593,6 +1604,7 @@ proc editview {} {
set newviewname($curview) $viewname($curview)
set newviewperm($curview) $viewperm($curview)
set newviewargs($curview) [shellarglist $viewargs($curview)]
+ set newviewargscmd($curview) [shellarglist $viewargscmd($curview)]
vieweditor $top $curview "Gitk: edit view $viewname($curview)"
}
@@ -1613,7 +1625,15 @@ proc vieweditor {top n title} {
grid $top.al - -sticky w -pady 5
entry $top.args -width 50 -textvariable newviewargs($n) \
-background white -font $uifont
+
grid $top.args - -sticky ew -padx 5
+ message $top.ac -aspect 1000 -font $uifont \
+ -text "Command to generate more commits to include:"
+ grid $top.ac - -sticky w -pady 5
+ entry $top.argscmd -width 50 -textvariable newviewargscmd($n) \
+ -background white -font $uifont
+
+ grid $top.argscmd - -sticky ew -padx 5
message $top.l -aspect 1000 -font $uifont \
-text "Enter files and directories to include, one per line:"
grid $top.l - -sticky w
@@ -1659,7 +1679,7 @@ proc allviewmenus {n op args} {
proc newviewok {top n} {
global nextviewnum newviewperm newviewname newishighlight
global viewname viewfiles viewperm selectedview curview
- global viewargs newviewargs viewhlmenu
+ global viewargs newviewargs viewargscmd newviewargscmd viewhlmenu
if {[catch {
set newargs [shellsplit $newviewargs($n)]
@@ -1669,6 +1689,14 @@ proc newviewok {top n} {
focus $top
return
}
+ if {[catch {
+ set newargscmd [shellsplit $newviewargscmd($n)]
+ } err]} {
+ error_popup "Error in commit selection command: $err"
+ wm raise $top
+ focus $top
+ return
+ }
set files {}
foreach f [split [$top.t get 0.0 end] "\n"] {
set ft [string trim $f]
@@ -1683,6 +1711,7 @@ proc newviewok {top n} {
set viewperm($n) $newviewperm($n)
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newargscmd
addviewmenu $n
if {!$newishighlight} {
run showview $n
@@ -1699,9 +1728,11 @@ proc newviewok {top n} {
doviewmenu $viewhlmenu 1 [list addvhighlight $n] \
entryconf [list -label $viewname($n) -value $viewname($n)]
}
- if {$files ne $viewfiles($n) || $newargs ne $viewargs($n)} {
+ if {$files ne $viewfiles($n) || $newargs ne $viewargs($n) || \
+ $newargscmd ne $viewargscmd($n)} {
set viewfiles($n) $files
set viewargs($n) $newargs
+ set viewargscmd($n) $newargscmd
if {$curview == $n} {
run updatecommits
}
@@ -7419,10 +7450,14 @@ catch {source ~/.gitk}
font create optionfont -family sans-serif -size -12
set revtreeargs {}
+set revtreeargscmd None
foreach arg $argv {
switch -regexp -- $arg {
"^$" { }
"^-d" { set datemode 1 }
+ "^--argscmd=" {
+ regexp {^--argscmd=(.*)} $arg match revtreeargscmd
+ }
default {
lappend revtreeargs $arg
}
@@ -7481,6 +7516,7 @@ set selectedhlview None
set viewfiles(0) {}
set viewperm(0) 0
set viewargs(0) {}
+set viewargscmd(0) None
set cmdlineok 0
set stopped 0
@@ -7494,7 +7530,7 @@ makewindow
wm title . "[file tail $argv0]: [file tail [pwd]]"
readrefs
-if {$cmdline_files ne {} || $revtreeargs ne {}} {
+if {$cmdline_files ne {} || $revtreeargs ne {} || $revtreeargscmd ne {}} {
# create a view for the files/dirs specified on the command line
set curview 1
set selectedview 1
@@ -7502,6 +7538,7 @@ if {$cmdline_files ne {} || $revtreeargs ne {}} {
set viewname(1) "Command line"
set viewfiles(1) $cmdline_files
set viewargs(1) $revtreeargs
+ set viewargscmd(1) $revtreeargscmd
set viewperm(1) 0
addviewmenu 1
.bar.view entryconf Edit* -state normal
@@ -7515,6 +7552,7 @@ if {[info exists permviews]} {
set viewname($n) [lindex $v 0]
set viewfiles($n) [lindex $v 1]
set viewargs($n) [lindex $v 2]
+ set viewargscmd($n) [lindex $v 3]
set viewperm($n) 1
addviewmenu $n
}
^ permalink raw reply related
* Re: [PATCH 1/3] rebase -i: handle --continue more like non-interactive rebase
From: Alex Riesen @ 2007-07-12 22:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <Pine.LNX.4.64.0707080300440.4093@racer.site>
Johannes Schindelin, Sun, Jul 08, 2007 04:01:29 +0200:
> Non-interactive rebase requires the working tree to be clean, but
> applies what is in the index without requiring the user to do it
> herself. Imitate that, but (since we are interactive, after all)
> fire up an editor with the commit message.
Could we also have "git rebase <base> <branch>"?
I find it useful when I have many branches to rebase:
~/project @master$ git rebase master branch1
~/project @branch1$ git rebase master branch2
~/project @branch2$ git rebase master branch3
...
Otherwise one have to, for example, "git checkout branch1" first,
and only then run rebase-interactive. Checkout is not very pleasant
operation on windows if you have many files (well, nothing is pleasant
there, but this one have to be done often). Rebase-interactive is
*very* slow there, but I just could not part with it after having
tried it once :)
^ permalink raw reply
* [PATCH] Fix git-rebase -i to allow squashing of fast-forwardable commits
From: Alex Riesen @ 2007-07-12 22:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Schindelin
Without this change the commits will be left standalone, with
duplicated commit message.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Noticed when trying to blend the second commit in a branch into the
first. Squash didn't work at all (apart from commit message
duplication).
git-rebase--interactive.sh | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index d9563ec..f395076 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -84,6 +84,7 @@ pick_one () {
current_sha1=$(git rev-parse --verify HEAD)
if [ $current_sha1 = $parent_sha1 ]; then
git reset --hard $sha1
+ test "a$1" = a-n && git reset --soft $current_sha1
sha1=$(git rev-parse --short $sha1)
warn Fast forward to $sha1
else
@@ -193,14 +194,14 @@ do_next () {
die "Cannot 'squash' without a previous commit"
mark_action_done
- failed=f
- pick_one -n $sha1 || failed=t
MSG="$DOTEST"/message
echo "# This is a combination of two commits." > "$MSG"
echo "# The first commit's message is:" >> "$MSG"
echo >> "$MSG"
git cat-file commit HEAD | sed -e '1,/^$/d' >> "$MSG"
echo >> "$MSG"
+ failed=f
+ pick_one -n $sha1 || failed=t
echo "# And this is the 2nd commit message:" >> "$MSG"
echo >> "$MSG"
git cat-file commit $sha1 | sed -e '1,/^$/d' >> "$MSG"
--
1.5.3.rc0.116.gc35c1-dirty
^ permalink raw reply related
* sharing between local "work" and "nightly build" git repos
From: David Frech @ 2007-07-12 23:36 UTC (permalink / raw)
To: git
I'd like to have the following setup: a ~david/git directory, where I
am free to work on things, and a ~david/nightly-git, where a cron job
is going build and test a nightly "next" branch.
I'd like to share as much as possible between the two repos. My naive
first attempt was to clone the local repo (~david/git) using -l and -s
(which I admit I do not completely understand). This sort of worked,
but one issue is that doing a "git pull" in nightly is going to pull
from the *locally*-cloned repo, not from the main git. Another is that
a checkout in nightly failed with the obscure error:
[david@tashtego ~/git-nightly]% git checkout -b nightly-next next
git checkout: updating paths is incompatible with switching branches/forcing
Did you intend to checkout 'next' which can not be resolved as commit?
I assume this is because too much state is being shared the repos, and
something is unfinished in the "git" directory.
I'd love some pointers on how to:
* share as many objects as possible
* share as little state as possible
* make git pull pull from remote in both repos.
Cheers,
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* [PATCH 2/3] Document long options '--message=<msg>' and '--no-commit'
From: Jakub Narebski @ 2007-07-12 23:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <11842844481113-git-send-email-jnareb@gmail.com>
Document that '--message=<msg>' is long version of '-m <msg>' in
git-commit, and that '--no-checkout' is long version of '-n' in
git-clone.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch was silently skipped in the 11 patches long series
of documenting undocumented long options
"[PATCH 00/11] Document missing options"
(or rather two patches which are concatenated into this one).
Documentation/git-clone.txt | 1 +
Documentation/git-commit.txt | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2f39864..a0a10e3 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -64,6 +64,7 @@ OPTIONS
Operate quietly. This flag is passed to "rsync" and
"git-fetch-pack" commands when given.
+--no-checkout::
-n::
No checkout of HEAD is performed after the clone is complete.
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 53a7bb0..352a494 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -71,7 +71,7 @@ OPTIONS
Override the author name used in the commit. Use
`A U Thor <author@example.com>` format.
--m <msg>::
+-m <msg>|--message=<msg>::
Use the given <msg> as the commit message.
-s|--signoff::
--
1.5.2.2
^ permalink raw reply related
* [PATCH 3/3] Document git commit --untracked-files and --verbose
From: Jakub Narebski @ 2007-07-12 23:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
In-Reply-To: <11842844481113-git-send-email-jnareb@gmail.com>
Documentation based on description of commit 443f8338 which added
'-u'|'--untracked-files' option to git-status, and on git-runstatus(1)
man page.
Note that those options apply also to git-status.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> +-u|--untracked-files::
>> + Show all untracked files, also those in uninteresting
>> + directories.
>> +
>> +-v|--verbose::
>> + Show the diff output between the HEAD commit and what
>> + would be committed.
>> +
>
> Thanks -- "show" sounds a bit funny, though, don't you think?
Is this one, with a longer description of options, better?
The previous version of this patch got skipped...
Documentation/git-commit.txt | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 352a494..f96142f 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -8,7 +8,7 @@ git-commit - Record changes to the repository
SYNOPSIS
--------
[verse]
-'git-commit' [-a | --interactive] [-s] [-v]
+'git-commit' [-a | --interactive] [-s] [-v] [-u]
[(-c | -C) <commit> | -F <file> | -m <msg> | --amend]
[--no-verify] [-e] [--author <author>]
[--] [[-i | -o ]<file>...]
@@ -115,6 +115,19 @@ but can be used to amend a merge commit.
as well. This is usually not what you want unless you
are concluding a conflicted merge.
+-u|--untracked-files::
+ Show all untracked files, also those in uninteresting
+ directories, in the "Untracked files:" section of commit
+ message template. Without this option only its name and
+ a trailing slash are displayed for each untracked
+ directory.
+
+-v|--verbose::
+ Show unified diff between the HEAD commit and what
+ would be committed at the bottom of the commit message
+ template. Note that this diff output doesn't have its
+ lines prefixed with '#'.
+
-q|--quiet::
Suppress commit summary message.
--
1.5.2.2
^ permalink raw reply related
* [PATCH 1/3] Document GIT_MERGE_VERBOSITY environmental variable
From: Jakub Narebski @ 2007-07-12 23:54 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jakub Narebski
While at it, add "Configuration" section mentioning merge.summary
configuration variable (which is mentioned in git-fmt-merge-msg(1)
man page, but it is a plumbing command), and merge.verbosity
configuration variable (so there is a place to make reference
from "Environment Variables" section of git(7) man page) to the
git-merge(1) man page.
The configuration variable merge.verbosity and environmental variable
GIT_MERGE_VERBOSITY were introduced in commit 8c3275ab, which also
documented configuration variable but not environmental variable.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The alternative to adding "Configuration" section to git-merge(1)
man page, and referring to it in the description of GIT_MERGE_VERBOSITY
environmental variable in git(7), would be to either refer to
git-config(1), or add full description similar to description of
merge.verbosity to git(7).
Perhaps above paragraph should be added to commit message?
I have put shortened sha1 of commit which introduced setting of
a merge verbosity to be able to go to it from graphical UI
like for example gitweb.
Documentation/config.txt | 1 +
Documentation/git-merge.txt | 15 +++++++++++++++
Documentation/git.txt | 5 +++++
3 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 4b67f0a..6cd0ff0 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -567,6 +567,7 @@ merge.verbosity::
message if conflicts were detected. Level 1 outputs only
conflicts, 2 outputs conflicts and file changes. Level 5 and
above outputs debugging information. The default is level 2.
+ Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
merge.<driver>.name::
Defines a human readable name for a custom low-level
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index d285cba..1442e06 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -43,6 +43,21 @@ If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with
gitlink:git-reset[1].
+CONFIGURATION
+-------------
+
+merge.summary::
+ Whether to include summaries of merged commits in newly
+ merge commit messages. False by default.
+
+merge.verbosity::
+ Controls the amount of output shown by the recursive merge
+ strategy. Level 0 outputs nothing except a final error
+ message if conflicts were detected. Level 1 outputs only
+ conflicts, 2 outputs conflicts and file changes. Level 5 and
+ above outputs debugging information. The default is level 2.
+ Can be overriden by 'GIT_MERGE_VERBOSITY' environment variable.
+
HOW MERGE WORKS
---------------
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 10c7bb3..895c25c 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -410,6 +410,11 @@ parameter, <path>.
other
~~~~~
+'GIT_MERGE_VERBOSITY'::
+ A number controlling the amount of output shown by
+ the recursive merge strategy. Overrides merge.verbosity.
+ See gitlink:git-merge[1]
+
'GIT_PAGER'::
This environment variable overrides `$PAGER`.
--
1.5.2.2
^ permalink raw reply related
* Re: [PATCH] gitweb: new cgi parameter: option
From: Jakub Narebski @ 2007-07-13 0:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vy7hltq98.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>> By the way, gitweb uses shortened names for paramaters. Perhaps 'opt'
>> or 'op' instead of 'options' here and in href subroutine (below)?
>
> Or even 'o' ;-).
'o' is used for 'order'/'ordering', to sort tables for some actions.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: sharing between local "work" and "nightly build" git repos
From: Junio C Hamano @ 2007-07-13 0:03 UTC (permalink / raw)
To: David Frech; +Cc: git
In-Reply-To: <7154c5c60707121636l585b42d4l931b08f1468ddfc@mail.gmail.com>
"David Frech" <nimblemachines@gmail.com> writes:
> I'd like to share as much as possible between the two repos. My naive
> first attempt was to clone the local repo (~david/git) using -l and -s
> (which I admit I do not completely understand). This sort of worked,
> but one issue is that doing a "git pull" in nightly is going to pull
> from the *locally*-cloned repo, not from the main git. Another is that
> a checkout in nightly failed with the obscure error:
>
> [david@tashtego ~/git-nightly]% git checkout -b nightly-next next
> git checkout: updating paths is incompatible with switching branches/forcing
> Did you intend to checkout 'next' which can not be resolved as commit?
>
> I assume this is because too much state is being shared the repos, and
> something is unfinished in the "git" directory.
You assumed wrong. "-l and -s" does not have to do anything
with the above symptoms.
git-clone helps people by setting up the new repository to
follow where you cloned from, but there is no rule that you
cannot change it. Look at .git/config in the nightly repository
and find [remote "origin"] section; update its URL to whichever
repository you would want to track from and you are done.
"git checkout -b nightly-next next" is telling git to:
- create a new branch nightly-next starting from 'next'
- check it out
You most likely would want to fork off of "origin/next", not
'next' which probably does not exist in your repository.
If you are willing to redo the nightly repository from scratch,
I would probably recommend using --reference option when
cloning, like this:
$ git clone --reference ~david/git git://git.kernel.org/... ~/nightly-git
$ cd ~/nightly-git
$ git checkout --track -b next origin/next
Then a nightly update would go like this:
$ cd ~/nightly-git
$ git pull origin next
$ make clean
$ make test || barf
^ permalink raw reply
* Re: git-update-server-info may be required,cannot clone and pull from a remote repository
From: Jakub Narebski @ 2007-07-13 0:17 UTC (permalink / raw)
To: pradeep singh; +Cc: Eric Wong, git
In-Reply-To: <a901b49a0707120550i9361e30wc5811bd5d3305f59@mail.gmail.com>
Pradeep Singh wrote:
> On 7/12/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> [Cc: git@vger.kernel.org, Pradeep Singh <pradeep.rautela@gmail.com>,
>> Eric Wong <normalperson@yhbt.net> (instaweb creator)]
>>
>> pradeep singh wrote:
>>
>>> Anyway i could not get gitweb running after running git-instaweb.
>>>
>>> Any thoughts on how to setup a gitweb interface ?
>>
>> What information does gitweb/INSTALL lack?
>
> May be I am running some old version on my Ubuntu Edgy machine
> perhaps? I cannot find such a file anywhere?
You can always look up this file at git.git gitweb (either kernel.org
one, or repo.or.cz one), e.g.
http://repo.or.cz/w/alt-git.git/:gitweb/INSTALL
> Looks like it is available in newer versions.
> Does it works for git-1.4.4?
The installation instructions may have changed a bit since then. It is
much easier to use 1.5.x series, nevertheless.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: sharing between local "work" and "nightly build" git repos
From: David Frech @ 2007-07-13 0:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmyy1rwza.fsf@assigned-by-dhcp.cox.net>
On 7/12/07, Junio C Hamano <gitster@pobox.com> wrote:
> "David Frech" <nimblemachines@gmail.com> writes:
> If you are willing to redo the nightly repository from scratch,
> I would probably recommend using --reference option when
> cloning, like this:
>
> $ git clone --reference ~david/git git://git.kernel.org/... ~/nightly-git
> $ cd ~/nightly-git
> $ git checkout --track -b next origin/next
>
> Then a nightly update would go like this:
>
> $ cd ~/nightly-git
> $ git pull origin next
> $ make clean
> $ make test || barf
This makes sense, including the --track, which I neglected to set.
Could you, for my sake and the list's (if others are as confused) be
clearer about the distinctions among -l, -s, and --reference? Exactly
what they do, and their orthogonality (or lack of) really isn't clear
from reading the man page.
Thanks for your help! I'll set this up and hopefully start running it tonight.
If the build or test barfs, who should get the mail?
BTW, I figured out a sneaky way (using filters in Gmail) to send it
thru my Gmail account, so I won't have any issues with sending via
SMTP from a dynamic IP.
Cheers,
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: sharing between local "work" and "nightly build" git repos
From: David Frech @ 2007-07-13 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7154c5c60707121727k36854891u82afc4a8be822861@mail.gmail.com>
On 7/12/07, David Frech <nimblemachines@gmail.com> wrote:
> On 7/12/07, Junio C Hamano <gitster@pobox.com> wrote:
> > Then a nightly update would go like this:
> >
> > $ cd ~/nightly-git
> > $ git pull origin next
> > $ make clean
> > $ make test || barf
One more thing: would it make sense to do "make -k test" so that *all*
failures (if >1) show up?
Cheers,
- David
--
If I have not seen farther, it is because I have stood in the
footsteps of giants.
^ permalink raw reply
* Re: Volume of commits
From: Jakub Narebski @ 2007-07-13 0:40 UTC (permalink / raw)
To: git
In-Reply-To: <m3ps2xu5hc.fsf@pc7.dolda2000.com>
Fredrik Tolf wrote:
> When I develop for myself, I usually commit incrementally quite a
> bit, if for no other reason because Git won't let me switch between
> branches if I don't commit first. I usually try to keep my commits
> well-defined, but I don't manage to get anywhere close to what I see
> when I look at the history of Linux or Git.
First, if you commit only to switch branches you can always instead
of adding commit on top of whis WIP commit, just --amend it.
Second, there is git-stash just created for saving state to go back
to it.
Third, I guess that the neat patch series are result of reworking
existing series using tools like StGIT (which I use and find very
nice to work with, going and correcting back and forth between patches
in series), or guilt (similar to StGIT), or git-gui, or new interactive mode
of git-rebase, or git-cherry-pick...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Lump commit HOWTO?
From: Josh Boyer @ 2007-07-13 1:21 UTC (permalink / raw)
To: Git Mailing List
Hi All,
I have a specific workflow in mind that I'm not entirely sure how to
accomplish with git. What I'd like to do is track a project in a
local branch, and do commits of my own there as well. Then when I'm
ready to submit the work, I want to take all the incremental commits
and lump them into a single new commit and push that out as a patch or
into a branch for people to pull from.
E.g.
1) clone upstream into foo branch
2) commit A
3) commit B
4) pull upstream changes into foo branch
5) commit C
6) commit D
7) repeat steps 2 - 6 in various orders
8) take all local commits (A - D) and create a single commit without
any of the upstream changes in it
Is something like that easily accomplished? Or perhaps a different
workflow that would allow similar results?
josh
^ permalink raw reply
* Re: [PATCH] reduce git-pack-objects memory usage a little more
From: Brian Downing @ 2007-07-13 1:42 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0707121703240.32552@xanadu.home>
On Thu, Jul 12, 2007 at 05:07:59PM -0400, Nicolas Pitre wrote:
> The delta depth doesn't have to be stored in the global object array
> structure since it is only used during the deltification pass.
This patch breaks pack-objects pretty horribly:
:; PATH=~/src/git:$PATH /usr/bin/time ~/src/git/git-repack -a -d -f
:; ls -l .git/objects/pack
total 153916
-r--r--r-- 1 bdowning bdowning 1312136 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.idx
-r--r--r-- 1 bdowning bdowning 156130933 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.pack
chain length = 1: 6182 objects
chain length = 2: 66 objects
chain length = 3: 27 objects
chain length = 4: 20 objects
chain length = 5: 15 objects
chain length = 6: 9 objects
chain length = 7: 5 objects
chain length = 8: 5 objects
chain length = 9: 6 objects
chain length = 10: 4 objects
chain length = 11: 6 objects
chain length = 12: 4 objects
chain length = 13: 3 objects
chain length = 14: 3 objects
chain length = 15: 2 objects
chain length = 16: 2 objects
chain length = 17: 1 object
chain length = 18: 1 object
chain length = 19: 1 object
Unfortunately I didn't notice until I tried v1.5.3-rc1...
-bcd
^ permalink raw reply
* Re: [PATCH] reduce git-pack-objects memory usage a little more
From: Brian Downing @ 2007-07-13 1:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <20070713014228.GE19073@lavos.net>
On Thu, Jul 12, 2007 at 08:42:28PM -0500, Brian Downing wrote:
> This patch breaks pack-objects pretty horribly:
>
> :; PATH=~/src/git:$PATH /usr/bin/time ~/src/git/git-repack -a -d -f
[that's Git I'm repacking here]
> :; ls -l .git/objects/pack
> total 153916
> -r--r--r-- 1 bdowning bdowning 1312136 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.idx
> -r--r--r-- 1 bdowning bdowning 156130933 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.pack
>
> chain length = 1: 6182 objects
> chain length = 2: 66 objects
> chain length = 3: 27 objects
> chain length = 4: 20 objects
> chain length = 5: 15 objects
> chain length = 6: 9 objects
> chain length = 7: 5 objects
> chain length = 8: 5 objects
> chain length = 9: 6 objects
> chain length = 10: 4 objects
> chain length = 11: 6 objects
> chain length = 12: 4 objects
> chain length = 13: 3 objects
> chain length = 14: 3 objects
> chain length = 15: 2 objects
> chain length = 16: 2 objects
> chain length = 17: 1 object
> chain length = 18: 1 object
> chain length = 19: 1 object
-bcd
^ permalink raw reply
* [PATCH] forgot to clear the depth value
From: Nicolas Pitre @ 2007-07-13 2:27 UTC (permalink / raw)
To: Junio C Hamano, Brian Downing; +Cc: git
In-Reply-To: <20070713014502.GF19073@lavos.net>
Commit 5a235b5e was missing this little detail. Otherwise your pack
will explode.
Problem noted by Brian Downing.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Thu, 12 Jul 2007, Brian Downing wrote:
> On Thu, Jul 12, 2007 at 08:42:28PM -0500, Brian Downing wrote:
> > This patch breaks pack-objects pretty horribly:
> >
> > :; PATH=~/src/git:$PATH /usr/bin/time ~/src/git/git-repack -a -d -f
>
> [that's Git I'm repacking here]
>
> > :; ls -l .git/objects/pack
> > total 153916
> > -r--r--r-- 1 bdowning bdowning 1312136 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.idx
> > -r--r--r-- 1 bdowning bdowning 156130933 2007-07-12 20:39 pack-9ac926ee1f5810c434707d3f816f5ad2cbd14668.pack
Oooooops.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index a43d604..5e9d1fd 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1431,6 +1431,7 @@ static void free_unpacked(struct unpacked *n)
window_memory_usage -= n->entry->size;
}
n->entry = NULL;
+ n->depth = 0;
}
static void find_deltas(struct object_entry **list, int window, int depth)
^ permalink raw reply related
* Re: [PATCH] forgot to clear the depth value
From: Junio C Hamano @ 2007-07-13 3:10 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Brian Downing, git
In-Reply-To: <alpine.LFD.0.999.0707122221240.32552@xanadu.home>
Gaaah ..... thanks.
^ permalink raw reply
* Re: mtimes of working files
From: Theodore Tso @ 2007-07-13 0:37 UTC (permalink / raw)
To: David Woodhouse; +Cc: Andy Parkins, git, Jan Hudec, Johannes Schindelin
In-Reply-To: <1184261246.31598.139.camel@pmac.infradead.org>
On Thu, Jul 12, 2007 at 06:27:26PM +0100, David Woodhouse wrote:
> On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:
> > The only time you get an unnecessary rebuild is if you do
> >
> > git checkout branch1
> > git checkout branch2
> > git checkout branch1
> >
> > But we can hardly expect git to be responsible for that.
>
> Indeed. That's a user error. Git makes it cheap and easy to have
> separate _trees_. Just use them -- branches are just another mental
> hangover from CVS which we should try to cure ourselves of :)
Personally, I just use branches a huge amount, and I will often do
git checkout branch1
<hack hack hack>
git commit --amend
<build, test>
git checkout branch2
<hack hack hack>
git commit
<build, test>
git checkout branch1
<build>
Rebuilding isn't a problem, because I use ccache. :-)
I could use separate trees, I suppose, but then I have to keep
multiple copies of the .o files around in all of those separate trees,
and it's cheaper and more efficient to keep them in the ccache cache
IMHO. And with 7200 RPM laptop drives and dual core processors
combined with ccache, I hardly notice the rebuild/relink time.
- Ted
^ 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