* git-rev-parse question.
From: Junio C Hamano @ 2005-08-23 8:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I have been looking at what git-rev-parse does and could not
figure out a way to convince it to give me only arguments with
a '-' prefix. Specifically, I wanted to remove the hardcoded -p
and -M flags from git-diff-script. Running
$ sh -x git-diff-script -C HEAD^ HEAD
reveals that none of the following would pick up "-C" from the
command line:
rev=($(git-rev-parse --revs-only "$@")) || exit
flags=($(git-rev-parse --no-revs --flags "$@"))
files=($(git-rev-parse --no-revs --no-flags "$@"))
I am not even sure if the current implementation of rev-parse
matches what you originally wanted it to do; I suspect it does
not. I would like to know what was the intended behaviour
first, so that I can enhance it to be usable for my purpose
without breaking things.
What I want the rev-parse flags to mean is as follows. By "rev
argument", I mean what get_sha1() can understand. I have to
admit that some flags are what I introduced while I was
butchering it without really knowing the original intention:
output format:
--sq output in a format usable for shell "eval".
--symbolic output rev argument in symbolic form, not SHA1.
output selection:
--flags show only arguments with '-' prefix.
--no-flags do not show arguments with '-' prefix.
--revs-only show only arguments meant for rev-list.
--no-revs show arguments not meant for rev-list.
input munging:
--default R if no revision, pretend R is given.
--not pretend all rev arguments without prefix ^ have
prefix ^, and the ones with prefix ^ do not.
--all pretend all refs under $GIT_DIR/refs are given
on the command line.
special:
--verify make sure only one rev argument is given, nothing else.
I think flags/no-flags and revs-only/no-revs *should* be
orthogonal. That is, "rev-parse --flags --no-revs" should give
parameters that start with '-' and not meant for rev-list
(e.g. '-C' in earlier example); "rev-parse --revs-only
--merge-order HEAD Documentation/" should yield "--merge-order
HEAD".
Also there is an undocumented --show-prefix. What is it?
-jc
PS. BTW, any response about unsuspecting companies?
^ permalink raw reply
* cg-update/cg-merge refuse to update if state is dirty?
From: Martin Langhoff @ 2005-08-23 8:09 UTC (permalink / raw)
To: GIT
Should cg-update or cg-merge be refusing to merge if the tree is
dirty? If there are uncommitted files, and the merge fails, a lot of
unrelated changes will be dumped on the working tree, which ends up
with a mix of things.
cheers,
martin
^ permalink raw reply
* [RFC] cg-log -r order:matters
From: Martin Langhoff @ 2005-08-23 11:12 UTC (permalink / raw)
To: GIT
It's sometimes unclear which head is "ahead" of the other. If I get
the order wrong, cg-log shows no log output. Is this expected?
I was expecting a warning, or a reverse-ordered log. Or both. ;)
martin
^ permalink raw reply
* gitk tree view
From: Ingo Bormuth @ 2005-08-23 4:24 UTC (permalink / raw)
To: git; +Cc: paulus, ingo
[-- Attachment #1: Type: text/plain, Size: 9043 bytes --]
Hi.
This is a quick hack which allows you to browser the entire tree using gitk.
Keybindings: n - toggle line numbers
v - toggle tree view
I know, it should be cleaned up. It needs some locking.
Colored diffs in the tree would be nice.
Is anybody interested in a propper version ???
Cheers Ingo
--
+--------------------------------------------------------+
| Ingo Bormuth, voicebox & telefax: +49-12125-10226517 |
| GnuPG key 86326EC9 at http://ibormuth.efil.de/contact |
+--------------------------------------------------------+
Added tree view.
This is a rather quick hack.
---
commit 4f697f79d6e82d0d0269eeda5f746174c6ba047e
tree c6f82a184da82ed417f170d1b7e2025a801c879b
parent 792fe559d02e55c12d2d544fd6d6f202cbaab6f4
author <ingo@kruemel.(none)> Tue, 23 Aug 2005 06:08:21 +0200
committer <ingo@kruemel.(none)> Tue, 23 Aug 2005 06:08:21 +0200
gitk | 189 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 183 insertions(+), 6 deletions(-)
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -329,12 +329,13 @@ proc makewindow {} {
global findtype findtypemenu findloc findstring fstring geometry
global entries sha1entry sha1string sha1but
global maincursor textcursor curtextcursor
- global rowctxmenu gaudydiff mergemax
+ global rowctxmenu gaudydiff mergemax viewmodebutton
menu .bar
.bar add cascade -label "File" -menu .bar.file
menu .bar.file
.bar.file add command -label "Reread references" -command rereadrefs
+ .bar.file add command -label "Toggle line numbers" -command togglelinenum
.bar.file add command -label "Quit" -command doquit
menu .bar.help
.bar add cascade -label "Help" -menu .bar.help
@@ -381,6 +382,9 @@ proc makewindow {} {
.ctop.top.clist add $canv3
bind .ctop.top.clist <Configure> {resizeclistpanes %W %w}
+ set viewmodebutton Tree
+ button .ctop.top.bar.viewmodebutton -textvariable viewmodebutton -command togglesetviewmode
+ pack .ctop.top.bar.viewmodebutton -side left
set sha1entry .ctop.top.bar.sha1
set entries $sha1entry
set sha1but .ctop.top.bar.sha1label
@@ -493,9 +497,11 @@ proc makewindow {} {
bindkey <Key-space> "$ctext yview scroll 1 pages"
bindkey p "selnextline -1"
bindkey n "selnextline 1"
+ bindkey l "togglelinenum"
bindkey b "$ctext yview scroll -1 pages"
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
+ bindkey v "toggleviewmode"
bindkey / {findnext 1}
bindkey <Key-Return> {findnext 0}
bindkey ? findprev
@@ -2056,7 +2062,7 @@ proc selectline {l isnew} {
global lineid linehtag linentag linedtag
global canvy0 linespc parents nparents children
global cflist currentid sha1entry
- global commentend idtags idline linknum
+ global commentend idtags idline linknum viewmodebutton
$canv delete hover
if {![info exists lineid($l)] || ![info exists linehtag($l)]} return
@@ -2815,10 +2821,173 @@ proc gettreediffline {gdtf ids} {
lappend treediff $file
}
+proc toggleviewmode {} {
+ global viewmodebutton selectedline
+ if { $viewmodebutton == "Commit" } {
+ set viewmodebutton Tree
+ } else {
+ set viewmodebutton Commit
+ }
+ if {![info exists selectedline]} return
+ set l [expr $selectedline]
+ selectline $l 1
+}
+
+proc togglelinenum {} {
+ global showlinenum selectedline
+ if { $showlinenum } { set showlinenum false } else { set showlinenum true }
+ if {![info exists selectedline]} return
+ set l [expr $selectedline]
+ selectline $l 1
+}
+
+proc viewfull { path } {
+ global ctext currentid viewpath
+ $ctext conf -state normal
+ $ctext delete 0.0 end
+
+ if { $viewpath == "Comments" || $path == "/" } {
+ set path ""
+ set viewpath ""
+ }
+ if { $path != "" } {
+ set viewpath $path
+ }
+
+ if [catch {set stream [open "|git-ls-tree $currentid $viewpath" r]}] {
+ $ctext insert end "ERROR: viewfull: git-ls-tree $currentid $viewpath"
+ return
+ }
+ gets $stream line
+ close $stream
+
+ set kind [lindex $line 1]
+ set sha [lindex $line 2]
+
+ if { $viewpath == "" } {
+ set kind root
+ set sha $currentid
+ }
+
+ if { $line == "" } {
+ set kind "NOT FOUND !!!"
+ }
+
+ viewheader $viewpath $kind
+
+ if { $kind == "blob"} {
+ viewblob $sha
+ } elseif { $kind == "tree" || $kind == "root"} {
+ viewtree $sha
+ }
+}
+
+proc viewheader { path kind } {
+ global ctext
+ $ctext insert end "type: $kind\n"
+ $ctext insert end "path: "
+
+ set splitpath [ linsert [ split [ string trim $path "/" ] "/" ] 0 "ROOT" ]
+ set name [ lindex $splitpath end ]
+ set splitpath [ lrange $splitpath 0 end-1 ]
+ set buildpath "/"
+ foreach next $splitpath {
+ if { $next != "ROOT" } {
+ append buildpath "$next/"
+ }
+ viewprintlink "$next" $buildpath
+ $ctext insert end " / "
+ }
+ $ctext insert end "$name \n"
+ set l [expr {(78 - [string length $name]) / 2}]
+ set pad [string range "----------------------------------------" 1 $l]
+ $ctext insert end "$pad $name $pad\n" filesep
+}
+
+proc viewprintlink { name path } {
+ global ctext
+ set linkbeg [$ctext index "end - 1c"]
+ $ctext insert end "$name"
+ set linkend [$ctext index "end - 1c"]
+ $ctext tag add linkfile$name "$linkbeg + 0 c" "$linkend + 0 c"
+ $ctext tag conf linkfile$name -foreground blue -underline 1
+ $ctext tag bind linkfile$name <Enter> { %W configure -cursor hand2 }
+ $ctext tag bind linkfile$name <Leave> { %W configure -cursor $curtextcursor }
+ $ctext tag bind linkfile$name <1> [ list viewfull "$path" ]
+}
+
+
+proc viewblob {sha} {
+ global ctext linenum
+ set linenum 0
+ if [catch {set stream [open "|git-cat-file blob $sha" r]}] {
+ $ctext insert end "ERROR: viewblob"
+ return
+ }
+ fconfigure $stream -blocking 0
+ fileevent $stream readable [list getviewblobline $stream $sha]
+}
+
+proc getviewblobline {stream sha} {
+ global ctext linenum showlinenum
+ set n [gets $stream line]
+ if {$n < 0} {
+ if {![eof $stream]} return
+ close $stream
+ return
+ }
+ incr linenum
+ set num [format "%5s" "$linenum"]
+ if { $showlinenum } { $ctext insert end "$num " hunksep }
+ $ctext insert end "$line\n"
+}
+
+proc viewtree {sha} {
+ global ctext lstree
+ set lstree ""
+ $ctext insert end "\n\n"
+ if [catch {set stream [open "|git-ls-tree $sha" r]}] {
+ $ctext insert end "ERROR viewtree"
+ return
+ }
+ fconfigure $stream -blocking 0
+ fileevent $stream readable [list getviewtreeline $stream]
+}
+
+proc getviewtreeline {stream} {
+ global ctext viewpath lstree
+ set n [gets $stream line]
+ if {$n < 0} {
+ if {![eof $stream]} return
+ close $stream
+ printviewtreefilter "tree"
+ $ctext insert end "\n"
+ printviewtreefilter "blob"
+ return
+ }
+ lappend lstree $line
+}
+
+proc printviewtreefilter {filter} {
+ global ctext lstree viewpath
+ foreach line $lstree {
+ set kind [ lindex $line 1 ]
+ if { $kind != $filter} continue
+ set name [ lindex $line 3 ]
+ $ctext insert end " $kind "
+ viewprintlink $name "$viewpath/$name"
+ $ctext insert end " \n"
+ }
+}
+
proc getblobdiffs {ids} {
global diffopts blobdifffd diffids env curdifftag curtagstart
- global difffilestart nextupdate diffinhdr treediffs
-
+ global difffilestart nextupdate diffinhdr treediffs viewmodebutton
+ # If the button says COMMIT, we are in TREE mode)
+ if { $viewmodebutton == "Commit" } {
+ viewfull ""
+ return
+ }
set id [lindex $ids 0]
set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
@@ -2951,12 +3120,18 @@ proc nextfile {} {
}
proc listboxsel {} {
- global ctext cflist currentid
+ global ctext cflist currentid viewmodebutton viewpath
if {![info exists currentid]} return
set sel [lsort [$cflist curselection]]
if {$sel eq {}} return
set first [lindex $sel 0]
- catch {$ctext yview fmark.$first}
+ set viewpath [ $cflist get $first ]
+ # If the button says COMMIT, we are in TREE mode
+ if {$viewmodebutton == "Commit"} {
+ viewfull [$cflist get $first]
+ } else {
+ catch {$ctext yview fmark.$first}
+ }
}
proc setcoords {} {
@@ -3576,6 +3751,8 @@ set stopped 0
set redisplaying 0
set stuffsaved 0
set patchnum 0
+set viewpath ""
+set showlinenum false
setcoords
makewindow
readrefs
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* arch2git import script
From: Martin Langhoff @ 2005-08-23 13:11 UTC (permalink / raw)
To: GIT, Catalin Marinas
First draft of an Arch import. Very limited but will import one
"branch" into one head. The basics are for it to follow branches, and
some support for marking merges (or at least what git would consider
merges.
TODO:
- proper branch switching
- binary file handling
- get the date format right!
- parse the output of cat-archive-log to know what files to add/delete
and cleanup the logmsg
- ensure all shell invocations have error handling
- allow multiple "Archives"
- learn to run repeatedly over the same git repo, importing only new commits
- track cherrypicking to identify how far branches are merged (in the
git sense)
- a few options as to how to follow (or not) the history
- follow a full branch starting from a full import "down" with
branches opening from it.
- follow a branch history "up"
An example invocation to import the sears-ldap-dev branch is:
mkdir sample-import
cd sample-import;
git-archimport-script -t /tmp/some/dir -i \
-A arch-eduforge@catalyst.net.nz--2004 sears-ldap--dev
the commit message needs cleanup, the dates are bogus, and we aren't
marking deletes... but it otherwise works great! ;)
cheers,
martin
^ permalink raw reply
* Re: arch2git import script
From: Martin Langhoff @ 2005-08-23 13:13 UTC (permalink / raw)
To: GIT, Catalin Marinas
In-Reply-To: <46a038f90508230611337c695e@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 169 bytes --]
On 8/24/05, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> First draft of an Arch import.
And now, with sample script attached, too.
cheers,
martin
[-- Attachment #2: git-archimport-script --]
[-- Type: application/octet-stream, Size: 8524 bytes --]
#!/usr/bin/perl -w
# This tool is copyright (c) 2005, Matthias Urlichs.
# It is released under the Gnu Public License, version 2.
#
# The basic idea is to walk the output of tla abrowse,
# fetch the changesets and apply them.
#
# The head revision is on branch "origin" by default.
# You can change that with the '-o' option.
use strict;
use warnings;
use Getopt::Std;
use File::Spec;
use File::Temp qw(tempfile);
use File::Path qw(mkpath);
use File::Basename qw(basename dirname);
use Time::Local;
use IO::Socket;
use IO::Pipe;
use POSIX qw(strftime dup2);
use Data::Dumper qw/ Dumper /;
use IPC::Open2;
$SIG{'PIPE'}="IGNORE";
$ENV{'TZ'}="UTC";
our($opt_h,$opt_A,$opt_v,$opt_k,
$opt_d,$opt_p,$opt_C,$opt_z,
$opt_i,$opt_t);
sub usage() {
print STDERR <<END;
Usage: ${\basename $0} # fetch/update GIT from Arch
[ -h ] [ -v ] [ -A archive ]
[ -C GIT_repository ] [ -t tempdir ]
[ arch-branch ]
END
exit(1);
}
getopts("hviA:C:t:") or usage();
usage if $opt_h;
@ARGV <= 1 or usage();
my $tmp = $opt_t;
$tmp ||= '/tmp';
$tmp .= '/git-archimport/';
my $git_tree = $opt_C;
$git_tree ||= ".";
my $arch_branch = '';
if ($#ARGV == 0) {
$arch_branch = $ARGV[0];
}
# TODO: handle more than one repo
open ABROWSE, "tla abrowse -f -A $opt_A --desc --merges $arch_branch |"
or die "Problems with tla abrowse: $!";
my @psets = (); # the collection
my %ps = (); # the current one
my $mode = '';
my $lastseen = '';
while (<ABROWSE>) {
chomp;
# first record padded w 8 spaces
if (s/^\s{8}\b//) {
# store the record we just captured
if (%ps) {
my %temp = %ps; # break references
push (@psets, \%temp);
%ps = ();
}
my ($id, $type) = split(m/\s{3}/, $_);
$ps{id} = $id;
# deal with types
if ($type =~ m/^\(simple changeset\)/) {
$ps{type} = 's';
} elsif ($type eq '(initial import)') {
$ps{type} = 'i';
} elsif ($type =~ m/^\(tag revision of (.+)\)/) {
$ps{type} = 't';
$ps{tag} = $1;
} else {
warn "Unknown type $type";
}
$lastseen = 'id';
}
if (s/^\s{10}//) {
# 10 leading spaces or more
# indicate commit metadata
# date & author
if ($lastseen eq 'id' && m/^\d{4}-\d{2}-\d{2}/) {
my ($date, $authoremail) = split(m/\s{2,}/, $_);
$ps{date} = "+0000 $date";
$authoremail =~ m/^(.+)\s(\S+)$/;
$ps{author} = $1;
$ps{email} = $2;
$lastseen = 'date';
} elsif ($lastseen eq 'date') {
# the only hint is position
# subject is after date
$ps{subj} = $_;
$lastseen = 'subj';
} elsif ($lastseen eq 'subj' && $_ eq 'merges in:') {
$ps{merges} = [];
$lastseen = 'merges';
} elsif ($lastseen eq 'merges' && s/^\s{2}//) {
push (@{$ps{merges}}, $_);
} else {
warn 'more metadata after merges!?';
}
}
}
if (%ps) {
my %temp = %ps; # break references
push (@psets, \%temp);
%ps = ();
}
close ABROWSE;
## Order patches by time
@psets = sort {$a->{date}.$b->{id} cmp $b->{date}.$b->{id}} @psets;
#print Dumper \@psets;
##
## TODO cleanup irrelevant patches
## and put an initial import
## or a full tag
if ($opt_i) { # initial import
if ($psets[0]{type} eq 'i' || $psets[0]{type} eq 't') {
print "Starting import from $psets[0]{id}\n";
} else {
die "Need to start from an import or a tag -- cannot use $psets[0]{id}";
}
`git-init-db`;
die $! if $?;
}
# process
my $lastbranch = branchname($psets[0]{id}); # only good for initial import
foreach my $ps (@psets) {
$ps->{branch} = branchname($ps->{id});
#
# ensure we have a clean state
#
if (`git diff-files`){
die "Unclean tree when about to process $ps->{id} " .
" - did we fail to commit cleanly before?";
}
die $! if $?;
#
# create the branch if needed
# TODO: Find the ancestor!
#
unless ( -e ".git/refs/heads/$ps->{branch}") {
`git checkout -b $ps->{branch}`;
} else {
`git checkout $ps->{branch}`;
}
die $! if $?;
#
# Apply the import/changeset/merge into the working tree
#
if ($ps->{type} eq 'i') {
apply_import($ps) or die $!;
} elsif ($ps->{type} eq 's') {
apply_cset($ps);
}
#
# prepare update git's index, based on what arch knows
# about the pset, resolve parents, etc
#
# =for reference
# A log entry looks like
# Revision: moodle-org--moodle--1.3.3--patch-15
# Archive: arch-eduforge@catalyst.net.nz--2004
# Creator: Penny Leach <penny@catalyst.net.nz>
# Date: Wed May 25 14:15:34 NZST 2005
# Standard-date: 2005-05-25 02:15:34 GMT
# New-files: lang/de/.arch-ids/block_glossary_random.php.id
# lang/de/.arch-ids/block_html.php.id
# New-directories: lang/de/help/questionnaire
# lang/de/help/questionnaire/.arch-ids
# Removed-files: lang/be/docs/.arch-ids/release.html.id
# lang/be/docs/.arch-ids/releaseold.html.id
# Modified-files: admin/cron.php admin/delete.php
# admin/editor.html backup/lib.php backup/restore.php
# New-patches: arch-eduforge@catalyst.net.nz--2004/moodle-org--moodle--1.3.3--patch-15
# Summary: Updating to latest from MOODLE_14_STABLE (1.4.5+)
# Keywords:
#
# Updating yadda tadda tadda madda
my ($logsummary, $logmessage, $tree);
{ # scope block for some vars
my $commitlog = `tla cat-archive-log -A $opt_A $ps->{id}`;
die "Error in cat-archive-log: $!" if $?;
# process_commitlog will git-add/rm files
# and generally prepare things for the commit
$logmessage = $commitlog;
# add all the files, re-adds will be ignored
`find . -type f -print0 | grep -zv '^./.git' | xargs -0 git-update-cache --add`;
# warn "errors when runnign git-update-cache! $!";
$tree = `git-write-tree`;
die "cannot write tree $!" if $?;
chomp $tree;
} # end scope block
#
# Commit and clean state
#
my @par;
if ( -e ".git/refs/heads/$ps->{branch}"){
if (open HEAD, "<.git/refs/heads/$ps->{branch}") {
my $p = <HEAD>;
close HEAD;
chomp $p;
push @par, '-p', $p;
} else {
if ($ps->{type} eq 's') {
warn "Could not find the right head for the branch $ps->{branch}";
}
}
}
my $par = join (' ', @par);
$ENV{GIT_AUTHOR_NAME} = $ps->{author};
$ENV{GIT_AUTHOR_EMAIL} = $ps->{email};
$ENV{GIT_COMMITTER_NAME} = $ps->{author};
$ENV{GIT_COMMITTER_EMAIL} = $ps->{email};
$ENV{COMMITTER_DATE} = $ps->{date};
my ($pid, $commit_rh, $commit_wh);
$commit_rh = 'commit_rh';
$commit_wh = 'commit_wh';
$pid = open2(*READER, *WRITER, "git-commit-tree $tree $par")
or die $!;
print WRITER $logmessage; # write
close WRITER;
my $commitid = <READER>; # read
chomp $commitid;
close READER;
waitpid $pid,0; # close;
if (length $commitid != 40) {
die "Something went wrong with the commit! $! $commitid";
}
#
# Update the branch
#
open HEAD, ">.git/refs/heads/$ps->{branch}";
print HEAD $commitid;
close HEAD;
unlink ('.git/HEAD');
symlink("refs/heads/$ps->{branch}",".git/HEAD");
print " * Committed $ps->{id}\n";
}
sub branchname {
my $id = shift;
$id =~ s#^.+?/##;
my @parts = split(m/--/, $id);
return join('--', @parts[0..1]);
}
sub apply_import {
my $ps = shift;
my $bname = branchname($ps->{id});
`mkdir -p $tmp`;
`tla get -s --no-pristine -A $opt_A $ps->{id} $tmp/import`;
die "Cannot get import: $!" if $?;
print "rsync --archive --delete --exclude '.git' --exclude '.arch-ids' --exclude '{arch}' $tmp/import/* ./";
print `rsync -v --archive --delete --exclude '.git' --exclude '.arch-ids' --exclude '{arch}' $tmp/import/* ./`;
die "Cannot rsync import:$!" if $?;
`rm -fr $tmp/import`;
die "Cannot remove tempdir: $!" if $?;
return 1;
}
sub apply_cset {
my $ps = shift;
`mkdir -p $tmp`;
# get the changeset
`tla get-changeset -A $opt_A $ps->{id} $tmp/changeset`;
die "Cannot get changeset: $!" if $?;
# apply patches
if (`find $tmp/changeset/patches -type f -name '*.patch'`) {
`(find $tmp/changeset/patches -type f -print0 -name '*.patch' | xargs -0 --no-run-if-empty cat ) | patch -p1 --verbose --forward `;
die "Problem applying patches! $!" if $?;
}
# bring in new files
`rsync --archive --exclude '.git' --exclude '.arch-ids' --exclude '{arch}' $tmp/changeset/new-files-archive/* ./`;
# deleted files are hinted from the commitlog processing
`rm -fr $tmp/changeset`;
}
^ permalink raw reply
* Re: cg-update/cg-merge refuse to update if state is dirty?
From: Carl Baldwin @ 2005-08-23 14:22 UTC (permalink / raw)
To: Martin Langhoff; +Cc: GIT
In-Reply-To: <46a038f905082301096285a3cb@mail.gmail.com>
Hello,
Here's a thought. It might be nice, in this situation, to have
something like a git-undo-script that can undo the changes in the index
storing them in a tree object but not wrapping them into a commit. A
ref to the tree can be stored in an 'undo' file somewhere under .git.
When the merge is done then a git-redo-script can retrieve and merge
that tree back into the index. This way, cg-{merge,update} could refuse
--- which I tend to think it should --- to merge into a dirty tree but
it wouldn't be so inconvenient.
cogito would handle synchronization with the working copy like normal.
Carl
On Tue, Aug 23, 2005 at 08:09:04PM +1200, Martin Langhoff wrote:
> Should cg-update or cg-merge be refusing to merge if the tree is
> dirty? If there are uncommitted files, and the merge fails, a lot of
> unrelated changes will be dumped on the working tree, which ends up
> with a mix of things.
>
> cheers,
>
>
> martin
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* [RFC] Removing deleted files after checkout
From: Carl Baldwin @ 2005-08-23 16:21 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
Hello,
I recently started using git to revision control the source for my
web-page. I wrote a post-update hook to checkout the files when I push
to the 'live' repository.
In this particular context I decided that it was important to me to remove
deleted files after checking out the new HEAD. I accomplished this by running
git-ls-files before and after the checkout.
Is there a better way? Could there be some way built into git to easily
find out what files dissappear when replacing the current index with one
from a new tree? Is there already? The behavior of git should NOT
change to delete these files but I would argue that some way should
exist to query what files disappeared if removing them is desired.
Here is some code that I wrote for this. It feels a bit hackish to me but I
couldn't think of anything better. Comments and criticism are welcome.
#!/bin/sh
# HEAD changed so checkout the new HEAD deleted any files that should no longer
# be around.
oldlist=$(tempfile)
newlist=$(tempfile)
removedlist=$(tempfile)
git-ls-files | sort -r > $oldlist
git-checkout-script -f
git-ls-files | sort -r > $newlist
diff -u $oldlist $newlist |
tail -n +4 |
sed -n 's/^-//p' > $removedlist
# Remove each file
cat $removedlist | xargs -rl rm -f
# Remove the directories if empty
cat $removedlist | xargs -rl dirname | xargs -rl rmdir -p --ignore-fail-on-non-empty
rm -f $oldlist $newlist $removedlist
# --- snip ---
If you are interested I attached the full post-update hook script that I
actually use to do this. Again, comments are welcome.
Thanks,
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[-- Attachment #2: post-update --]
[-- Type: text/plain, Size: 827 bytes --]
#!/bin/sh
export PATH=/usr/local/bin:/usr/bin:/bin
# cd to the root of the project directory (assume one dir up from GIT_DIR)
cd $GIT_DIR/..
unset GIT_DIR
# Set up some temporary files and a trap to delete them
oldlist=$(tempfile)
newlist=$(tempfile)
removelist=$(tempfile)
trap "rm -f $oldlist $newlist $removelist" 0 1 2 3 15
# Get list of files from the current index
git-ls-files | sort -r > $oldlist
# Checkout the index to the working directory
git-checkout-script -f
# Get list of files from the current (new) index
git-ls-files | sort -r > $newlist
# Use diff to determine which files to remove from the working copy
diff -u $oldlist $newlist |
tail -n +4 |
sed -n 's/^-//p' > $removelist
cat $removelist | xargs -rl rm -f
cat $removelist | xargs -rl dirname | xargs -rl rmdir -p --ignore-fail-on-non-empty
^ permalink raw reply
* [PATCH] Improve can_hardlink diagnostics, remove suggest_hardlink
From: Pavel Roskin @ 2005-08-23 16:23 UTC (permalink / raw)
To: Petr Baudis, git
Hello!
suggest_hardlink is write-only in cg-pull - remove it. can_hardlink
should not be shown to the user as is (it's either "l" or empty) - we
should output something meaningful instead.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-pull b/cg-pull
--- a/cg-pull
+++ b/cg-pull
@@ -207,7 +207,6 @@ fetch_local()
cp_flags_l="-vdpR"
if [ "$1" = "-u" ]; then
cp_flags_l="$cp_flags_l -fu$can_hardlink"
- suggest_hardlink=
shift
fi
@@ -293,12 +292,16 @@ else
symlinked=
is_same_repo "$_git_objects" "$uri/objects" && symlinked=1
- # See if we can hardlink and drop "l" if not.
+ # See if we can hardlink and add "-l" to cp flags.
can_hardlink=
sample_file=$(find $uri -type f -print | head -n 1)
rm -f $_git/.,,lntest
- ln "$sample_file" "$_git/.,,lntest" 2>/dev/null && can_hardlink=l
- echo $can_hardlink
+ if cp -fl "$sample_file" "$_git/.,,lntest" 2>/dev/null; then
+ can_hardlink=l
+ echo "Using hard links"
+ else
+ echo "Hard links don't work - using copy"
+ fi
rm -f $_git/.,,lntest
fi
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Catalin Marinas @ 2005-08-23 16:55 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Jan Veldeman, git
In-Reply-To: <Pine.LNX.4.63.0508221707520.23242@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> One factor not mentioned there is that, as things move upstream, we often
> want to discard a lot of history; if someone commits constantly to deal
> with editor malfunction or something, we don't really want to take all of
> this junk into the project history when it is cleaned up and
> accepted.
That's true but Jan's proposal is to choose which commits to preserve
in the history via a 'freeze' command. That's a bit difficult to
implement in a clean way since the patches are floating on top of the
stack base and they change every time the base changes. It is possible
that a previous frozen state might no longer apply on top of a new
base.
> So the point is that there are things which are, in fact, parents, but we
> don't want to list them, because it's not desired information.
What's the definition of a parent in GIT terms? What are the
restriction for a commit object to be a parent? Can a parent be an
arbitrarily chosen commit?
> Probably the right thing is to have two views of the stack: the internal
> view, showing what actually happened, and the external view, showing what
> would have happened if the developers had done everything right the first
> time. When you make changes to the series, this adds to the internal view
> and entirely replaces the external view.
That's what I've been thinking. StGIT currently only implements the
external view.
An StGIT patch is a represented by a top and bottom commit
objects. The bottom one is the same as the parent of the top
commit. The patch is the diff between the top's tree id and the
bottom's tree id.
Jan's proposal is to allow a freeze command to save the current top
hash and later be used as a second parent for the newly generated
top. The problem I see with this approach is that (even for the
internal view you described) the newly generated top will have two
parents, new-bottom and old-top, but only the diff between new-top and
new-bottom is meaningful. The diff between new-top and old-top (as a
parent-child relation) wouldn't contain anything relevant to the patch
but all the new changes to the base of the stack.
Is the above an acceptable usage of the GIT DAG structure?
> I think that users will also want to discard the commits from the stack
> before rebasing in favor of the commits after, because (a) rebasing isn't
> all that interesting, especially if there's minimal merging, and (b)
> otherwise you'd get a ton of boring commits that obscure the interesting
> ones.
StGIT does this currently. The old commit is no longer available and
can be pruned (I still need to save the commits corresponding to the
unpushed patches since prune would remove those as well).
> I think that the best rule would be that, when you modify a patch, the
> previous version is the new version's parent, and when you rebase a
> series, you include as a parent any parent of the input that isn't also in
> the input (but never include the input itself as a parent of the output;
> the point of rebasing is to pretend that it was the newer mainline that
> you modified). This should mean that the internal history of a patch
> consists of the present version, based on each version that was replaced
> due to changing the patch rather than rebasing it.
Since you proposed this, my above usage of the DAG structure would be
fine then.
> Of course, there's an interesting situation with the commits earlier in a
> series from a patch that was changed not being ancestors of the newer
> versions of those patches (because they weren't interesting in the
> development of those patches) but accessible as the commits that an
> interesting patch was based on.
>
> A possible solution is just to consider the revision of any patch a
> significant event in the history of the whole stack, causing all of the
> patches to get a new retained version.
That's another idea to think about.
--
Catalin
P.S. I'll be away until next week and not able to follow-up the
discussions.
^ permalink raw reply
* Re: git-rev-parse question.
From: Linus Torvalds @ 2005-08-23 17:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jedulli.fsf@assigned-by-dhcp.cox.net>
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> I have been looking at what git-rev-parse does and could not
> figure out a way to convince it to give me only arguments with
> a '-' prefix.
Gaah. Understandable. It got broken during some cleanup.
Try this trivial patch, it should work better.
NOTE! The behaviour of "--" for git-rev-parse is somewhat unclear. Right
now it prints it out with "--flags", which is probably wrong.
Linus
---
Subject: Fix git-rev-parse --default and --flags handling
This makes the argument to --default and any --flags arguments should up
correctly.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,7 +107,7 @@ static void show_arg(char *arg)
if (do_rev_argument && is_rev_argument(arg))
show_rev_arg(arg);
else
- show_norev(arg);
+ show(arg);
}
static void show_default(void)
@@ -122,7 +122,7 @@ static void show_default(void)
show_rev(NORMAL, sha1, s);
return;
}
- show_arg(s);
+ show(s);
}
}
^ permalink raw reply
* Current status toward 0.99.5 and beyond
From: Junio C Hamano @ 2005-08-23 17:14 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
Some people may have noticed that the progress of the master
branch head has somewhat slowed down lately, and I have kept
some changes in the proposed updates branch for quite some time.
There are two reasons for this. One is that I've been quite
busy during my day job hours, and haven't had enough time to
make sure the multi-head fetch stuff does not break things and
the way it works is reasonable. Another is that I am feeling
guilty about letting Documentation go stale, and am reluctant to
have what is in the proposed updates branch graduate to the
master branch without accompanying documentation. Maybe I'll
have some time on my next GIT day [*1*].
Anyway, here is my updated Itchlist, as a preview of what comes
next.
For 0.99.5, I would like to finish testing and documenting what
is currently in the proposed updates branch. There are two
changes there: multi-head fetch and $GIT_DIR/remotes/ that
somewhat deprecates $GIT_DIR/branches/; semantics cleanup of
"git reset" command.
Linus has been feeding updates to make various commands to be
capable of running from subdirectories and taking paths relative
to the current directory. I would have liked these patches with
test scripts to demonstrate they do what they claim to do well.
Patches to extend existing test scripts in t/ directory are very
much welcomed. So far, the following commands should be usable
with relative directory paths:
update-cache
ls-files
diff-files
diff-cache
diff-tree
I do not have major itch after 0.99.5 right now, except for
obvious fixes and tweaks here and there [*2*]. I think we would
concentrate a bit more on usability enhancement including the
tutorial updates. One code change I would like to see is to add
limited MIME support to applymbox suite. We should be able to
teach mailinfo to:
- detect B encoding in the mail headers, and translate it to UTF-8;
- understand a single level multipart and pick out the body of
the message;
- detect QP in the body and decode into the original charset;
- after splitting the body into commit log and patch, translate only
the commit log part into UTF-8.
[Footnote]
*1* Currently, my Wednesdays and Saturdays are for GIT only.
*2* Here is a list of minor itches:
* "git rebase" could be a bit more tolerant to conflicting
patches. We may want to "wiggle" it, or may want to run
3-way "merge".
* The semantics of rev-parse needs to be clarified.
* show-branch may want to show things in topological order, not
time-based order.
* There are commands that were well intentioned but not useful
in practice, like build-rev-cache. I would like to review
them for removal.
* Cloning a packed repository over HTTP should work natively
now. Update "git clone" and remove "git-clone-dumb-http".
^ permalink raw reply
* Re: Current status toward 0.99.5 and beyond
From: Linus Torvalds @ 2005-08-23 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzn8poc8.fsf@assigned-by-dhcp.cox.net>
On Tue, 23 Aug 2005, Junio C Hamano wrote:
>
> So far, the following commands should be usable with relative directory
> paths:
>
> update-cache
> ls-files
> diff-files
> diff-cache
> diff-tree
Also, git-rev-parse.
Finally, this trivial patch makes "git-rev-list" also able to handle not
being in the top-level directory, which makes it possible to do "git log"
and "git-whatchanged" at any point in the directory structure.
Linus
---
Subject: Make "git-rev-list" work within subdirectories
This trivial patch makes ""git-rev-list" able to handle not being in the
top-level directory. This magically also makes "git-whatchanged" do the
right thing.
Trivial scripting fix to make sure that "git log" also works.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-log-script b/git-log-script
--- a/git-log-script
+++ b/git-log-script
@@ -1,5 +1,4 @@
#!/bin/sh
-. git-sh-setup-script || die "Not a git archive"
-revs=$(git-rev-parse --revs-only --default HEAD "$@")
+revs=$(git-rev-parse --revs-only --default HEAD "$@") || exit
[ "$revs" ] || die "No HEAD ref"
git-rev-list --pretty $(git-rev-parse --default HEAD "$@") | LESS=-S ${PAGER:-less}
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -481,6 +481,7 @@ static void handle_one_commit(struct com
int main(int argc, char **argv)
{
struct commit_list *list = NULL;
+ const char *prefix = setup_git_directory();
int i, limited = 0;
for (i = 1 ; i < argc; i++) {
^ permalink raw reply
* Re: git-rev-parse question.
From: Linus Torvalds @ 2005-08-23 17:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508231004180.3317@g5.osdl.org>
On Tue, 23 Aug 2005, Linus Torvalds wrote:
>
> Try this trivial patch, it should work better.
Actually, don't do the "show_default()" part of this. We should _not_ show
the default string if we haev "--no-revs" and the string doesn't match a
rev.
Also, this fixes "--" handlign with "--flags". Thinking about it for a
few seconds made it obvious that we shouldn't show it.
Linus
---
Subject: Fix git-rev-parse --default and --flags handling
This makes the argument to --default and any --flags arguments should up
correctly, and makes "--" together with --flags act sanely.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/rev-parse.c b/rev-parse.c
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -107,7 +107,7 @@ static void show_arg(char *arg)
if (do_rev_argument && is_rev_argument(arg))
show_rev_arg(arg);
else
- show_norev(arg);
+ show(arg);
}
static void show_default(void)
@@ -122,7 +122,7 @@ static void show_default(void)
show_rev(NORMAL, sha1, s);
return;
}
- show_arg(s);
+ show_norev(s);
}
}
@@ -149,7 +149,7 @@ int main(int argc, char **argv)
if (*arg == '-') {
if (!strcmp(arg, "--")) {
show_default();
- if (revs_only)
+ if (revs_only || flags_only)
break;
as_is = 1;
}
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Daniel Barkalow @ 2005-08-23 18:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Jan Veldeman, git
In-Reply-To: <tnxvf1wd24m.fsf@arm.com>
On Tue, 23 Aug 2005, Catalin Marinas wrote:
> > So the point is that there are things which are, in fact, parents, but we
> > don't want to list them, because it's not desired information.
>
> What's the definition of a parent in GIT terms? What are the
> restriction for a commit object to be a parent? Can a parent be an
> arbitrarily chosen commit?
Something is legitimate as a parent if someone took that commit and did
something to it to get the new commit. The operation which caused the
change is not specified. But you only want to include it if anyone cares
about the parent.
(For example, I often start with a chunk of work that does multiple things
and is committed; I take mainline and generate a series of commits from
there. It would be legitimate to list my development commit as a parent of
each of these, since I did actually take it and strip out the unrelated
changes. This would be a bit confusing in the log, but would make merges
between something based on the "messy" version and something based on the
"refined" version work well. On the other hand, I don't want to report the
existance of the messy version, so I don't include it.)
> An StGIT patch is a represented by a top and bottom commit
> objects. The bottom one is the same as the parent of the top
> commit. The patch is the diff between the top's tree id and the
> bottom's tree id.
>
> Jan's proposal is to allow a freeze command to save the current top
> hash and later be used as a second parent for the newly generated
> top. The problem I see with this approach is that (even for the
> internal view you described) the newly generated top will have two
> parents, new-bottom and old-top, but only the diff between new-top and
> new-bottom is meaningful. The diff between new-top and old-top (as a
> parent-child relation) wouldn't contain anything relevant to the patch
> but all the new changes to the base of the stack.
Having a useful diff isn't really a requirement for a parent; the diff in
the case of a merge is going to be the total of everything that happened
elsewhere. The point is to be able to reach some commits between which
there are interesting diffs.
This also depends on how exactly freeze is used; if you use it before
commiting a modification to the patch without rebasing, you get:
old-top -> new-top
^ ^
\ /
bottom
bottom to old-top is the old patch
bottom to new-top is the new patch
old-top to new-top is the change to the patch
Then you want to keep new-top as a parent for rebasings until one of these
is frozen. These links are not interesting to look at, but preserve the
path to the old-top:new-top change, which is interesting.
Ignoring the links to the corresponding bottoms, the development therefore
looks like:
local1 -> local2 -> merge -> local3 -> merge
^ ^ ^
mainline---->-->--------->------>-->----->
And this is how development is normally supposed to look. The trick is to
only include a minimal number of merges.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Daniel Barkalow @ 2005-08-23 19:43 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050823162156.GA32240@hpsvcnb.fc.hp.com>
On Tue, 23 Aug 2005, Carl Baldwin wrote:
> Hello,
>
> I recently started using git to revision control the source for my
> web-page. I wrote a post-update hook to checkout the files when I push
> to the 'live' repository.
>
> In this particular context I decided that it was important to me to remove
> deleted files after checking out the new HEAD. I accomplished this by running
> git-ls-files before and after the checkout.
>
> Is there a better way? Could there be some way built into git to easily
> find out what files dissappear when replacing the current index with one
> from a new tree? Is there already? The behavior of git should NOT
> change to delete these files but I would argue that some way should
> exist to query what files disappeared if removing them is desired.
If you don't use -f, git-checkout-script removes deleted files. Using -f
tells it to ignore the old index, which means that it can't tell the
difference between removed files and files that weren't tracked at all.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Improve handling of "." and ".." in git-diff-*
From: Alex Riesen @ 2005-08-23 19:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508162037080.3553@g5.osdl.org>
On 8/17/05, Linus Torvalds <torvalds@osdl.org> wrote:
> NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> you have people who do
BTW, could this (below) be useful for something?
#include <string.h>
#include <stdio.h>
#include <stdlib.h>
// an analog of "cd path" from a directory "cwd".
char* pathexpand(const char* cwd, const char* path)
{
static const char SEP[] = "/";
if ( !*path ) // empty path -> "." (don't move)
path = ".";
if ( !*cwd || *SEP == *path ) // no cwd, or path begins with "/"
cwd = SEP;
int len = strlen(cwd);
char* out = (char*)malloc(len + 1 + strlen(path) + 1);
char* p = strcpy(out, cwd) + len;
if ( *SEP != p[-1] )
*p++ = *SEP;
for ( ; *path; ++path )
{
char * pl = p;
while ( *path && *SEP != *path )
*p++ = *path++;
*p = '\0';
if ( p == pl ) /* ..."//"... */
; // just ignore
/* ..."/./"... */
else if ( p - pl == 1 && '.' == *pl )
--p; // just ignore
/* ..."/../"... */
else if ( p - pl == 2 && '.' == pl[0] && '.' == pl[1] )
{
// drop last element of the resulting path
if ( --pl > out )
for ( --pl; pl > out && *SEP != *pl; --pl );
p = ++pl;
}
/* ..."/path/"... */
else if ( *path )
*p++ = *path; // just add the separator
if ( !*path )
break;
}
if ( p > out+1 && *SEP == p[-1] )
--p;
*p = '\0';
return out;
}
#ifdef CHECK_PATHEXPAND
static void check(const char * cwd, const char * path, const char * good)
{
static int n = 0;
printf("%-2d: %s$ cd %s", ++n, cwd, path);
char* t = pathexpand(cwd, path);
if ( strcmp(t, good) )
printf(" failed(%s)\n", t);
else
printf(" \t\t%s\n", t);
free(t);
}
int main(int argc, char** argv)
{
/* 1 */ check("/onelevel", "aa", "/onelevel/aa");
/* 2 */ check("/", "..", "/");
/* 3 */ check("/", "../..", "/");
/* 4 */ check("/one", "aa/../bb", "/one/bb");
/* 5 */ check("/one/two", "aa//bb", "/one/two/aa/bb");
/* 6 */ check("", "/aa//bb", "/aa/bb");
/* 7 */ check("/one/two", "", "/one/two");
/* 8 */ check("/one/two", "aa/..bb/x/../cc/", "/one/two/aa/..bb/cc");
/* 9 */ check("/one/two", "aa/x/././cc////", "/one/two/aa/x/cc");
/* 10 */ check("/one/two", "../../../../aa", "/aa");
return 0;
}
#endif
^ permalink raw reply
* Re: Improve handling of "." and ".." in git-diff-*
From: Alex Riesen @ 2005-08-23 19:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <81b0412b050823124938d735bf@mail.gmail.com>
On 8/23/05, Alex Riesen <raa.lkml@gmail.com> wrote:
> On 8/17/05, Linus Torvalds <torvalds@osdl.org> wrote:
> > NOTE! This does _not_ handle ".." or "." in the _middle_ of a pathspec. If
> > you have people who do
>
> BTW, could this (below) be useful for something?
>
Well, a bit of explanation is certainly missing, sorry. The code tries
to emulate
(on purely text level) the behaviour of chdir(2), including stopping at root,
going back and forth and removing useless (not changing directory)
parts like "/./".
The file in the previous message can be tested with :
gcc -DCHECK_PATHEXPAND patchexpand.c && ./aout
Cheers,
Alex Riesen.
PS: Before anyone asked: the code is mine and free for any use.
^ permalink raw reply
* Re: [PATCH] Introduce "reset type" flag to "git reset"
From: Sam Ravnborg @ 2005-08-23 20:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vu0hhzcj1.fsf@assigned-by-dhcp.cox.net>
> I am not sure what mixed reset (the current behaviour) is good
> for. If nobody comes up with a good use case it may not be a
> bad idea to remove it.
Using the principle of minimum suprise the --mixed should be removed.
--soft - undo the commit leaving all changes.
--hard - undo the commit and removing all changes
I'm a cogito user so not used to got options.
But --soft, --hard looks rather confusing to me.
Something like --force or --prune may be a bit more intuitive, and let
default behaviour be the one you name --soft for now.
I think it would make sense to be able to specify the topmost SHA1 (or
HEAD:5 or HEAD^^^^^) from where the reset should start.
Sam
^ permalink raw reply
* Re: [RFC] Removing deleted files after checkout
From: Carl Baldwin @ 2005-08-23 20:50 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Carl Baldwin, git
In-Reply-To: <Pine.LNX.4.63.0508231533570.23242@iabervon.org>
On Tue, Aug 23, 2005 at 03:43:56PM -0400, Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Carl Baldwin wrote:
>
> > Hello,
> >
> > I recently started using git to revision control the source for my
> > web-page. I wrote a post-update hook to checkout the files when I push
> > to the 'live' repository.
> >
> > In this particular context I decided that it was important to me to remove
> > deleted files after checking out the new HEAD. I accomplished this by running
> > git-ls-files before and after the checkout.
> >
> > Is there a better way? Could there be some way built into git to easily
> > find out what files dissappear when replacing the current index with one
> > from a new tree? Is there already? The behavior of git should NOT
> > change to delete these files but I would argue that some way should
> > exist to query what files disappeared if removing them is desired.
>
> If you don't use -f, git-checkout-script removes deleted files. Using -f
> tells it to ignore the old index, which means that it can't tell the
> difference between removed files and files that weren't tracked at all.
Maybe I'm doing something wrong. This does not happen for me.
I tried a simple test with git v0.99.4...
cd
mkdir test-git && cd test-git/
echo testing | cg-init
echo contents > file
git-add-script file
git-commit-script -m 'testing'
cd ..
cg-clone test-git/.git/ test-git2
cd test-git2
cg-rm file
git-commit-script -m 'testing'
ls
cg-push
cd ../test-git
git-checkout-script
ls
git-status-script
At this point, I want 'file' to be gone. It is, however, still there.
That is the situation that my code was meant to handle. Maybe you were
thinking of something different? Maybe there is new code since 0.99.4?
Now, I think it would be wrong for git-checkout-script to actually
remove files unless an option were given to do so. So, the behavior
that I observe is correct in my opinion. I'm looking for a way to find
out what files should be deleted if that is desired.
Thanks,
Carl
> -Daniel
> *This .sig left intentionally blank*
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* "git checkout" says Entry blah would be overwritten by merge ...
From: tony.luck @ 2005-08-23 20:59 UTC (permalink / raw)
To: git
I'm a little closer to understanding how I got into the situation
where I made that ugly commit last week that included 10 files that
I didn't want, because I just had another failed merge (but this
time I know how to recover :).
The approximate sequence of events was:
SGI told me one of the pending fixes in my test tree was causing
an oops during boot on a whole class of machines. They asked whether
it could get into 2.6.13. I agreed it was a good candidate, and ran
my script to pull it from its temporary branch (named prarit-bus-sysdata
in this case) into my release branch. The script is trivial after the
argument sanity checks it just does:
$ git checkout release && git resolve release prarit-bus-sysdata "Pull prarit-bus-sysdata into release branch"
Only one file was touched by this:
arch/ia64/sn/kernel/io_init.c
I think that this would have gone through a non-trivial merge as this file
had subsequently been touched by another patch, but the merge did complete
automatically.
Next I pushed the release branch up to kernel.org, asked Linus to pull.
I then applied a totally independent patch to a new branch, pulled it
to the test branch, and pushed to kernel.org ... net effect was that
my tree ended up in "git checkout test" state.
Later I noticed that Linus had pulled from my tree (and from other
trees too), so I pulled his latest tree down from kernel.org using:
$ git checkout linus && git pull linus
Then I tried to update my test branch with these changes using:
$ git checkout test && git resolve test linus "Auto-update from upstream"
This spat out these messages:
fatal: Entry 'arch/ia64/sn/kernel/io_init.c' would be overwritten by merge. Cannot merge.
Trying to merge 8065e2... into cde7fe...
fatal: Entry 'arch/ia64/hp/sim/boot/boot_head.S' would be overwritten by merge. Cannot merge.
There is one obvious bug here: "git checkout test" failed with the first error (from
its invocation of git-read-tree) ... but returned an exit status of 0, so my
script went ahead and tried to do the resolve, which the && should have
prevented.
The less obvious (i.e. I have no clue what I did wrong) thing is why the
"git checkout" had a problem with this file. Yes, it had been touched
earlier ... but in a way that should have left the index up to date. And
two subsequent "git checkout" commands had switched first to the test
branch, and then to the linus branch without a complaint.
-Tony
^ permalink raw reply
* Automatic merge failed, fix up by hand
From: Len Brown @ 2005-08-23 21:12 UTC (permalink / raw)
To: git
I'm having trouble using git for merging kernel trees.
git seems to manufacture conflicts in files that
I never touched, and on some files it completely
throws up its arms, see "Not handling case" below.
Not clear how I got into this state -- probably
something to do with adding commits on branches
and them git-pull-branch'ing them into the master;
combined with updating the master from-linus.
when i switch heads, I simply remove .git/HEAD
and link it to the refs/heads/master or refs/heads/acpi-2.6.12
followed by a git checkout -f. To merge the work
back into the master I switch back to the master
and git-pull-branch per jeff's howto. I also
periodically pull from-linus after switching
the branch back to the master.
The merge issue below is reproduced in a "git clone -l" copy
with no plain files present.
Got any tips on how to recover?
thanks,
-Len
[lenb@firebird to-akpm.latest]$ git pull ../../from-linus
Packing 842 objects
Unpacking 842 objects
100% (842/842) done
Trying to merge 81065e2f415af6c028eac13f481fb9e60a0b487b into
702c7e7626deeabb057b6f529167b65ec2eefbdb
Simple merge failed, trying Automatic merge
Auto-merging CREDITS.
Removing Documentation/DocBook/scsidrivers.tmpl
Removing Documentation/dvb/README.dibusb
Removing Documentation/i2c/chips/smsc47b397.txt
Removing Documentation/i2c/sysfs-interface
Removing Documentation/networking/wanpipe.txt
Auto-merging MAINTAINERS.
merge: warning: conflicts during merge
ERROR: Merge conflict in MAINTAINERS.
Removing arch/arm/configs/omnimeter_defconfig
Removing arch/arm/kernel/arch.c
Removing arch/arm/lib/longlong.h
Removing arch/arm/lib/udivdi3.c
Removing arch/arm/mach-omap/Kconfig
Removing arch/arm/mach-omap/Makefile
Removing arch/arm/mach-omap/Makefile.boot
Removing arch/arm/mach-omap/board-generic.c
Removing arch/arm/mach-omap/board-h2.c
Removing arch/arm/mach-omap/board-h3.c
Removing arch/arm/mach-omap/board-innovator.c
Removing arch/arm/mach-omap/board-netstar.c
Removing arch/arm/mach-omap/board-osk.c
Removing arch/arm/mach-omap/board-perseus2.c
Removing arch/arm/mach-omap/board-voiceblue.c
Removing arch/arm/mach-omap/clock.c
Removing arch/arm/mach-omap/clock.h
Removing arch/arm/mach-omap/common.c
Removing arch/arm/mach-omap/common.h
Removing arch/arm/mach-omap/dma.c
Removing arch/arm/mach-omap/fpga.c
Removing arch/arm/mach-omap/gpio.c
Removing arch/arm/mach-omap/irq.c
Removing arch/arm/mach-omap/leds-h2p2-debug.c
Removing arch/arm/mach-omap/leds-innovator.c
Removing arch/arm/mach-omap/leds-osk.c
Removing arch/arm/mach-omap/leds.c
Removing arch/arm/mach-omap/leds.h
Removing arch/arm/mach-omap/mcbsp.c
Removing arch/arm/mach-omap/mux.c
Removing arch/arm/mach-omap/ocpi.c
Removing arch/arm/mach-omap/pm.c
Removing arch/arm/mach-omap/sleep.S
Removing arch/arm/mach-omap/time.c
Removing arch/arm/mach-omap/usb.c
Auto-merging arch/arm/mm/Kconfig.
Auto-merging arch/arm/mm/proc-v6.S.
Auto-merging arch/arm/nwfpe/softfloat.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/arm/nwfpe/softfloat.c.
Auto-merging arch/i386/kernel/acpi/boot.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/i386/kernel/acpi/boot.c.
Auto-merging arch/i386/kernel/acpi/sleep.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/i386/kernel/acpi/sleep.c.
Auto-merging arch/i386/kernel/apic.c.
Auto-merging arch/i386/kernel/nmi.c.
Auto-merging arch/ia64/Kconfig.
Auto-merging arch/ia64/configs/sn2_defconfig.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/configs/sn2_defconfig.
Auto-merging arch/ia64/configs/tiger_defconfig.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/configs/tiger_defconfig.
Auto-merging arch/ia64/configs/zx1_defconfig.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/configs/zx1_defconfig.
Auto-merging arch/ia64/kernel/acpi.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/kernel/acpi.c.
Auto-merging arch/ia64/kernel/domain.c.
Auto-merging arch/ia64/kernel/iosapic.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/kernel/iosapic.c.
Auto-merging arch/ia64/kernel/perfmon.c.
Removing arch/ia64/sn/include/pci/pcibr_provider.h
Removing arch/ia64/sn/include/pci/pic.h
Removing arch/ia64/sn/include/pci/tiocp.h
Auto-merging arch/ia64/sn/kernel/io_init.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ia64/sn/kernel/io_init.c.
Removing arch/mips/vr41xx/common/giu.c
Removing arch/ppc/boot/utils/addSystemMap.c
Removing arch/ppc/syslib/ppc4xx_kgdb.c
Removing arch/ppc64/boot/mknote.c
Removing arch/ppc64/boot/piggyback.c
Auto-merging arch/ppc64/kernel/LparData.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/ppc64/kernel/LparData.c.
Auto-merging arch/ppc64/kernel/Makefile.
Removing arch/ppc64/kernel/XmPciLpEvent.c
Auto-merging arch/ppc64/kernel/head.S.
Removing arch/ppc64/kernel/iSeries_pci_reset.c
Auto-merging arch/ppc64/kernel/iommu.c.
Auto-merging arch/sparc64/kernel/traps.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/sparc64/kernel/traps.c.
Auto-merging arch/um/kernel/skas/process.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/um/kernel/skas/process.c.
Removing arch/um/kernel/skas/time.c
Removing arch/um/kernel/tt/time.c
Removing arch/um/kernel/tt/unmap.c
Auto-merging arch/um/os-Linux/elf_aux.c.
Auto-merging arch/x86_64/kernel/smpboot.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in arch/x86_64/kernel/smpboot.c.
Auto-merging arch/x86_64/mm/fault.c.
Auto-merging drivers/acpi/Kconfig.
Auto-merging drivers/acpi/container.c.
Auto-merging drivers/acpi/osl.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/osl.c.
Auto-merging drivers/acpi/pci_bind.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/pci_bind.c.
Auto-merging drivers/acpi/pci_irq.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/pci_irq.c.
Auto-merging drivers/acpi/pci_link.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/pci_link.c.
Auto-merging drivers/acpi/pci_root.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/pci_root.c.
Auto-merging drivers/acpi/processor_core.c.
Auto-merging drivers/acpi/processor_idle.c.
Auto-merging drivers/acpi/scan.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/scan.c.
Auto-merging drivers/acpi/sleep/poweroff.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/acpi/sleep/poweroff.c.
Auto-merging drivers/base/bus.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/base/bus.c.
Auto-merging drivers/base/class.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/base/class.c.
Removing drivers/base/class_simple.c
Auto-merging drivers/char/hpet.c.
Removing drivers/i2c/chips/adm1021.c
Removing drivers/i2c/chips/adm1025.c
Removing drivers/i2c/chips/adm1026.c
Removing drivers/i2c/chips/adm1031.c
Removing drivers/i2c/chips/asb100.c
Removing drivers/i2c/chips/ds1621.c
Removing drivers/i2c/chips/fscher.c
Removing drivers/i2c/chips/fscpos.c
Removing drivers/i2c/chips/gl518sm.c
Removing drivers/i2c/chips/gl520sm.c
Removing drivers/i2c/chips/it87.c
Removing drivers/i2c/chips/lm63.c
Removing drivers/i2c/chips/lm75.c
Removing drivers/i2c/chips/lm75.h
Removing drivers/i2c/chips/lm77.c
Removing drivers/i2c/chips/lm78.c
Removing drivers/i2c/chips/lm80.c
Removing drivers/i2c/chips/lm83.c
Removing drivers/i2c/chips/lm85.c
Removing drivers/i2c/chips/lm87.c
Removing drivers/i2c/chips/lm90.c
Removing drivers/i2c/chips/lm92.c
Removing drivers/i2c/chips/max1619.c
Removing drivers/i2c/chips/pc87360.c
Removing drivers/i2c/chips/sis5595.c
Removing drivers/i2c/chips/smsc47b397.c
Removing drivers/i2c/chips/smsc47m1.c
Removing drivers/i2c/chips/via686a.c
Removing drivers/i2c/chips/w83627hf.c
Removing drivers/i2c/chips/w83781d.c
Removing drivers/i2c/chips/w83l785ts.c
Auto-merging drivers/ide/Kconfig.
Removing drivers/ide/cris/ide-v10.c
Auto-merging drivers/ide/ide-floppy.c.
Auto-merging drivers/ide/pci/generic.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/ide/pci/generic.c.
Auto-merging drivers/ide/pci/serverworks.c.
Auto-merging drivers/ide/ppc/pmac.c.
Auto-merging drivers/ide/setup-pci.c.
Removing drivers/input/gameport/cs461x.c
Removing drivers/input/gameport/vortex.c
Removing drivers/isdn/hisax/enternow.h
Removing drivers/isdn/hisax/st5481_hdlc.c
Removing drivers/isdn/hisax/st5481_hdlc.h
Removing drivers/isdn/sc/debug.c
Removing drivers/macintosh/macserial.c
Removing drivers/macintosh/macserial.h
Auto-merging drivers/md/md.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/md/md.c.
Removing drivers/media/dvb/b2c2/skystar2.c
Removing drivers/media/dvb/dibusb/Kconfig
Removing drivers/media/dvb/dibusb/Makefile
Removing drivers/media/dvb/dibusb/dvb-dibusb-core.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-dvb.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-fe-i2c.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-firmware.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-remote.c
Removing drivers/media/dvb/dibusb/dvb-dibusb-usb.c
Removing drivers/media/dvb/dibusb/dvb-dibusb.h
Removing drivers/media/dvb/dibusb/dvb-fe-dtt200u.c
Removing drivers/mtd/maps/db1550-flash.c
Removing drivers/mtd/maps/db1x00-flash.c
Removing drivers/mtd/maps/elan-104nc.c
Removing drivers/mtd/maps/pb1550-flash.c
Removing drivers/mtd/maps/pb1xxx-flash.c
Removing drivers/mtd/nand/tx4925ndfmc.c
Removing drivers/mtd/nand/tx4938ndfmc.c
Auto-merging drivers/net/8139cp.c.
ERROR: drivers/net/dm9000.c: Not handling case ->
5fddc0ff887822fde5cbf904e3db8e46b4becca1 ->
6440a892bb813ca4a08e0a1878cf0dedb43b254d
Removing drivers/net/fmv18x.c
Removing drivers/net/sk_g16.c
Removing drivers/net/sk_g16.h
Removing drivers/net/skfp/lnkstat.c
Removing drivers/net/skfp/smtparse.c
Removing drivers/net/smc-mca.h
Auto-merging drivers/net/tg3.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/net/tg3.c.
Removing drivers/pci/hotplug/acpiphp_pci.c
Removing drivers/pci/hotplug/acpiphp_res.c
Auto-merging drivers/pci/msi.c.
Auto-merging drivers/pci/quirks.c.
Auto-merging drivers/pnp/card.c.
Removing drivers/scsi/pci2000.c
Removing drivers/scsi/pci2220i.c
Removing drivers/scsi/pci2220i.h
Removing drivers/scsi/psi_dale.h
Removing drivers/scsi/psi_roy.h
Removing drivers/serial/bast_sio.c
Auto-merging drivers/serial/sn_console.c.
Removing drivers/usb/atm/usb_atm.c
Removing drivers/usb/atm/usb_atm.h
Auto-merging drivers/usb/input/wacom.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in drivers/usb/input/wacom.c.
Auto-merging drivers/usb/net/zd1201.c.
Removing fs/freevxfs/vxfs_kcompat.h
ERROR: fs/ioprio.c: Not handling case ->
97e1f088ba00b3b63f7f9ea594b756781fcf6596 ->
d1c1f2b2c9da9796affc6be18b8793489b9f2873
Auto-merging fs/jffs2/symlink.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/jffs2/symlink.c.
Auto-merging fs/jfs/inode.c.
Auto-merging fs/jfs/jfs_logmgr.c.
Auto-merging fs/jfs/jfs_logmgr.h.
Auto-merging fs/jfs/jfs_txnmgr.c.
Auto-merging fs/jfs/super.c.
Auto-merging fs/jfs/symlink.c.
Auto-merging fs/namei.c.
Auto-merging fs/nfs/dir.c.
Auto-merging fs/nfs/file.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/nfs/file.c.
Auto-merging fs/nfs/inode.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/nfs/inode.c.
ERROR: fs/nfs/nfs3acl.c: Not handling case ->
1b7a3ef2f8131f4f9c02534f55d5a42de4633f67 ->
6a5bbc0ae941aa690e1f73137cbce4af38902092
Auto-merging fs/nfs/nfs3proc.c.
Auto-merging fs/nfs/nfs4proc.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/nfs/nfs4proc.c.
Auto-merging fs/nfs/proc.c.
Auto-merging fs/nfs/read.c.
ERROR: fs/nfs_common/nfsacl.c: Not handling case ->
18c58c32e326281bfa7226edbaaec135b45c2b70 ->
251e5a1bb1c4cbe0308c042073b0d83cfe71d73d
Auto-merging fs/nfsd/nfssvc.c.
Auto-merging fs/ntfs/ChangeLog.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/ntfs/ChangeLog.
Auto-merging fs/ntfs/aops.c.
Auto-merging fs/ntfs/mft.c.
Auto-merging fs/proc/base.c.
Auto-merging fs/reiserfs/inode.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in fs/reiserfs/inode.c.
Auto-merging fs/sysfs/symlink.c.
Auto-merging include/acpi/acpi_bus.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/acpi/acpi_bus.h.
Auto-merging include/acpi/acpi_drivers.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/acpi/acpi_drivers.h.
Auto-merging include/asm-i386/processor.h.
Auto-merging include/asm-ia64/iosapic.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/asm-ia64/iosapic.h.
Removing include/asm-m32r/m32102peri.h
Removing include/asm-ppc/fsl_ocp.h
Auto-merging include/asm-ppc/ibm44x.h.
Removing include/asm-ppc64/iSeries/HvCallCfg.h
Removing include/asm-ppc64/iSeries/LparData.h
Auto-merging include/asm-ppc64/iSeries/LparMap.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/asm-ppc64/iSeries/LparMap.h.
Removing include/asm-ppc64/iSeries/XmPciLpEvent.h
Removing include/asm-ppc64/iSeries/iSeries_proc.h
Auto-merging include/asm-sh/unistd.h.
Auto-merging include/asm-sparc64/thread_info.h.
Auto-merging include/asm-x86_64/processor.h.
Auto-merging include/linux/acpi.h.
Auto-merging include/linux/fs.h.
Removing include/linux/ioc4_common.h
Removing include/linux/netfilter_ipv4/lockhelp.h
Auto-merging include/linux/nfs_fs.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/linux/nfs_fs.h.
Removing include/linux/pci-dynids.h
Auto-merging include/linux/pci.h.
Auto-merging include/linux/pci_ids.h.
Auto-merging include/linux/sunrpc/xdr.h.
merge: warning: conflicts during merge
ERROR: Merge conflict in include/linux/sunrpc/xdr.h.
Removing include/linux/xattr_acl.h
Auto-merging include/net/ax25.h.
Auto-merging include/net/sock.h.
Auto-merging kernel/sched.c.
Auto-merging kernel/signal.c.
Auto-merging kernel/timer.c.
Auto-merging mm/shmem.c.
Auto-merging net/decnet/dn_neigh.c.
Auto-merging net/ipv4/icmp.c.
Auto-merging net/ipv4/ipcomp.c.
Auto-merging net/ipv4/tcp.c.
Auto-merging net/ipv4/tcp_ipv4.c.
Auto-merging net/ipv4/tcp_output.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in net/ipv4/tcp_output.c.
Removing net/ipv4/utils.c
Auto-merging net/ipv6/ipcomp6.c.
Auto-merging net/ipv6/netfilter/ip6_queue.c.
Auto-merging net/ipv6/raw.c.
Auto-merging net/ipv6/tcp_ipv6.c.
Auto-merging net/sched/sch_generic.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in net/sched/sch_generic.c.
Auto-merging net/sunrpc/xdr.c.
merge: warning: conflicts during merge
ERROR: Merge conflict in net/sunrpc/xdr.c.
Removing sound/pcmcia/vx/vx_entry.c
Removing sound/pcmcia/vx/vxp440.c
Auto-merging sound/ppc/pmac.c.
fatal: merge program failed
Automatic merge failed, fix up by hand
^ permalink raw reply
* [PATCH] Fix git-checkout-script exit status
From: tony.luck @ 2005-08-23 21:03 UTC (permalink / raw)
To: git
Sometimes the git-read-tree in git-checkout-script fails for me.
Make sure that the failed status is passed up to caller.
Signed-off-by: Tony Luck <tony.luck@intel.com>
---
diff --git a/git-checkout-script b/git-checkout-script
--- a/git-checkout-script
+++ b/git-checkout-script
@@ -72,4 +72,6 @@ if [ "$?" -eq 0 ]; then
fi
[ "$branch" ] && ln -sf "refs/heads/$branch" "$GIT_DIR/HEAD"
rm -f "$GIT_DIR/MERGE_HEAD"
+else
+ exit 1
fi
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Jan Veldeman @ 2005-08-23 21:23 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Catalin Marinas, git
In-Reply-To: <Pine.LNX.4.63.0508231304130.23242@iabervon.org>
Daniel Barkalow wrote:
> On Tue, 23 Aug 2005, Catalin Marinas wrote:
>
> Something is legitimate as a parent if someone took that commit and did
> something to it to get the new commit. The operation which caused the
> change is not specified. But you only want to include it if anyone cares
> about the parent.
This is indeed what I thought a parent should be used for. As an adition,
I'll try to explain why I would sometimes want to care about some parents:
I want to track a mailine tree, but have quite a few changes, which shoudn't
be commited to the mainline immediately (let's call it my development tree).
This is why I would use stgit. But I would also want to colaborate with
other developers on this development tree, so I sometimes want to make
updates available of this development tree to the others. This is where
current stgit falls short. To easily share this development tree, I want
some history (not all, only the ones I choose) of this development tree
included, so that the other developers can easily follow my development.
The parents which should be visible to the outside, will always be versions
of my development tree, which I have previously pushed out. My way of
working would become:
* make changes, all over the place, using stgit
* still make changes (none of these gets tracked, intermittent versions are
lost)
* having a good day: changes looks good, I want to push this out:
* push my tree out
* stgit-free (which makes the pushed out commits, the new parents of my
stgit patches)
* restart from top
[...]
> This also depends on how exactly freeze is used; if you use it before
> commiting a modification to the patch without rebasing, you get:
>
> old-top -> new-top
> ^ ^
> \ /
> bottom
>
> bottom to old-top is the old patch
> bottom to new-top is the new patch
> old-top to new-top is the change to the patch
>
> Then you want to keep new-top as a parent for rebasings until one of these
> is frozen. These links are not interesting to look at, but preserve the
> path to the old-top:new-top change, which is interesting.
my proposal does something like this, but a little more: not only does it
keep track of the link between old-top and new-top, it also keeps track of
the links between old-patch-in-between and new-patch-in-between.
(This makes sense when the top is being removed or reordered)
I hope this kind of clarifies my intension.
Thank you for clarifying the meaning of parents.
Best regards,
Jan
^ permalink raw reply
* Re: [PATCH] Spell __attribute__ correctly in cache.h.
From: Jason Riedy @ 2005-08-23 21:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64u1ya7c.fsf@assigned-by-dhcp.cox.net>
And Junio C Hamano writes:
- > BTW, how would people feel about replacing the
- > setenv() and unsetenv() calls with the older putenv()?
- No comment on this one at this moment until I do my own digging
- a bit.
If you're interested, I have a few patches in
http://www.cs.berkeley.edu/~ejr/gits/git.git#portable
that let git compile with xlc on AIX and Sun's non-c99
cc on Solaris. Changes:
+ Replace C99 array initializers with code.
+ Replace unsetenv() and setenv() with older putenv().
+ Include sys/time.h in daemon.c.
+ Fix ?: statements.
+ Replace zero-length array decls with [].
The top two may or may not be acceptable. The third may
not be necessary if I can find the right -Ds for fd_set.
The last two just remove GNU C extensions. Makefile
changes (including extra -Ds for features) not included,
but could be. Tell me if you want any of these mailed.
Not all the tests pass on non-Linux, but I won't have time
to look at them for a bit. With the GNU findutils and
coreutils, it works well enough for basic use. The failing
tests might be from using non-GNU utilities. Rooting out
all the dependencies is a tad painful.
Jason
^ 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