* Re: Where should I post questions on GIT usage ?
From: Martin Langhoff @ 2005-11-10 10:06 UTC (permalink / raw)
To: Franck, Git Mailing List
In-Reply-To: <cda58cb80511100017v12f8ec77v@mail.gmail.com>
On 11/10/05, Franck <vagabon.xyz@gmail.com> wrote:
> I'm starting using GIT, and I'm having a couple of basic questions to
> ask. Is it the correct place to post them or is there any other
> mailing list related to GIT usage ?
Hi Franck,
I think you'll be fine posting here ;-) Everyone's been patient with
me so far. OTOH, the list has a good search facility at
marc.theaimsgroup.com , and GIT already has reasonable documentation,
including a tutorial and a few howtos, reachable at
http://www.kernel.org/pub/software/scm/git/docs/
regards,
martin
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Yaacov Akiba Slama @ 2005-11-10 9:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>Although I did not hear anybody jumping up-and-down to merge
>svnimport updates from Yaacov Akiba Slama, I did not hear it
>broke things either, so it graduated to the master branch and
>included in this release. It obviously improved things for
>Yaacov, and I am hoping this would not cause disruptions for
>people's existing setup.
>
>
Thanks for the merge.
IMHO, the commit labelled
"Bundle file copies from multiple branches into a merge"
(109fc2b97b73090a4a0a6550cdf9b2446fd12389) needs more attention/discussion.
In svn, there is no concept of branches or tag, but because the copy is
cheap, directories are used to simulate branches and tags.
The repository will be like :
/trunk/path/to/file
/branches/branch_1/path/to/file
/branches/branch_n/path/to/file
/tags/tag_1/path/to/file
/tags/tag_m/path/to/file
Now, someone can copy directory or files from the trunk or any
branch/tag into any other directory. For instance one can commit the
following tree as a new revision :
/trunk/path/to/file
/trunk/new/path/to/file (this is a copy of /branches/branch_1/path/to/file)
/branches/branch_1/path/to/file
/branches/branch_n/path/to/file
/tags/tag_1/path/to/file
/tags/tag_m/path/to/file
Now the commit 109fc2b97b73090a4a0a6550cdf9b2446fd12389 creates a new
commit with two parents:
1) HEAD
2) the git branch called "branch_1"
From what I read about the definition of commit in git's documentation,
that seems to be ok, but can this marking of "branch_1" as a parent of
this commit be dangerous for merges done later in pure git ?
--yas
^ permalink raw reply
* Re: git binary directory?
From: Petr Baudis @ 2005-11-10 9:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vvez4s6zv.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 07, 2005 at 06:27:48PM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> It looks like that both you and Pasky are not so enthusiastic
> about moving thing out of /usr/bin/, so let's keep things the
> way they are for 1.0 release and rethink when we do 2.0 (or
> whatever comes after 1.0).
Well, just to clarify - I'm personally not opposed to it, as long as it
gets done in some timeframe where it won't drastically break backwards
compatibility (that is, not in 1.0.1 or such, but e.g. at some right
moment before 1.0 or at the start of the next development series
whenever that happens), and as long as I get a way to get the path
of the git commands by a single fork().
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Petr Baudis @ 2005-11-10 9:40 UTC (permalink / raw)
To: Ben Clifford; +Cc: Git Mailing List, Blaisorblade, Nikolai Weibull
In-Reply-To: <33CE6BA8-415D-405F-89B3-982811C3A0CF@hawaga.org.uk>
Dear diary, on Thu, Nov 10, 2005 at 02:59:09AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> There are a few small common functions that are used by all the git
> completions, though. I suppose for going into cogito's contrib/ I
> should include them directly in cogito completion code, but that
> seems a little messy, as it would be nice to keep them in-sync with
> what is used in the other completion files. hmm.
Then could you please separate those from the git completion to some
kind of 'library'?
Dear diary, on Thu, Nov 10, 2005 at 07:57:34AM CET, I got a letter
where Ben Clifford <benc@hawaga.org.uk> said that...
> On 10 Nov 2005, at 09:23, Petr Baudis wrote:
> >Besides, it would be probably best to just autogenerate the
> >auto-completion code - the usage information in Cogito is supposed
> >to be
> >100% consistent and correct, so it should be a reliable source for
> >that.
>
> Maybe reliable and consistent but I think that info would need a bit
> of augmentation to use for specifying autocompletion - for example,
> in the case of:
>
> > Usage: cg-branch-add BRANCH_NAME LOCATION
>
> BRANCH_NAME should *not* exist so it doesn't make sense to
> autocomplete from the branch list, but in the case of:
When you do
cat > <tab><tab>
bash happily autocompletes as well. I don't think this is a problem,
besides it can be useful when you want to use some existing branch name,
just slightly modified.
> The amount of augmentation is probably not too much - probably
> sufficient to specify for each parameter a completion-source(s)
> (heads, branches, filenames, blah) that doesn't get displayed in --
> help. But this is more information to maintain and get out of date...
It's enough if we auto-build the completion and complain loudly and
error out when we hit something unknown.
> (I confess to having pretty much no idea how zsh completion works...)
Me neither. :-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: [PATCH] Add --pretty=fuller
From: Andreas Ericsson @ 2005-11-10 9:11 UTC (permalink / raw)
Cc: git
In-Reply-To: <7vzmod58ot.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> git log without --pretty showed author and author-date, while
> with --pretty=full showed author and committer but no dates.
> The new formatting option, --pretty=fuller, shows both name and
> timestamp for author and committer.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> ---
>
> * again, likes, dislikes, don't-cares?
>
Why not use:
--show=cdm,atn
for
Committer: date, mail
Author: timestamp,name
or
--show-author=date,timestamp,name
--show-committer=name,time
--show=name,date (for both author and committer)
or some such, with --pretty=<something> just a short-hand for those
show-options?
We'll run out of superlatives really quickly if there are more author
and committer info added sometime in the future, while the --show
flag(s) can be extended more or less indefinitely.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9g
From: Jeff Garzik @ 2005-11-10 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> - One important newcomer is git-pack-redundant. It is still in
> "pu" not because I doubt what it does is useful, but simply
> because I have not had a chance to study how it does its
> thing. I expect to fully merge it into "master" before 1.0
> happens.
IMHO git-prune-packed should prune redundant pack files...
> Oh, and we will not be moving things out of /usr/bin/ during 1.0
> timeframe.
:( bummer. I do like the elegance of having /usr/bin/git executing
stuff out of /usr/libexec/git.
/usr/libexec/git also makes it IMO cleaner when integrating git plugins
from third parties (rpm -Uvh git-newfeature), because you don't have to
worry about the /usr/bin namespace.
Jeff
^ permalink raw reply
* Re: [PATCH] Add --pretty=fuller
From: Johannes Schindelin @ 2005-11-10 8:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzmod58ot.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 9 Nov 2005, Junio C Hamano wrote:
> * again, likes, dislikes, don't-cares?
melikes.
On a side note: what would --pretty=fullest contain? ;-)
Ciao,
Dscho
^ permalink raw reply
* Where should I post questions on GIT usage ?
From: Franck @ 2005-11-10 8:17 UTC (permalink / raw)
To: git
Hi,
I'm starting using GIT, and I'm having a couple of basic questions to
ask. Is it the correct place to post them or is there any other
mailing list related to GIT usage ?
Thanks
--
Franck
^ permalink raw reply
* [ANNOUNCE] GIT 0.99.9g
From: Junio C Hamano @ 2005-11-10 8:14 UTC (permalink / raw)
To: git; +Cc: linux-kernel
GIT 0.99.9g is found at usual places. There are a couple of
important changes, as the slow march towards 1.0 continues.
- The RPM package has been split into a few packages by Jim
Radford. Unfortunately I am not equipped sufficiently to
test the resulting RPMs, so please feed me updates and
corrections as needed. I think archimport part needs to be
split out just like its svn/cvs cousins, and perhaps
documentation into another separate package.
- Fredrik Kuivinen's merge-recursive strategy is now the
default merge strategy for two-head merge that happens after
git-pull. I do not expect this to cause major disruptions,
but if this breaks things there is a workaround to override
this [*1*].
Although I did not hear anybody jumping up-and-down to merge
svnimport updates from Yaacov Akiba Slama, I did not hear it
broke things either, so it graduated to the master branch and
included in this release. It obviously improved things for
Yaacov, and I am hoping this would not cause disruptions for
people's existing setup.
Also included are unexciting bits of fixes here and there.
On the "proposed updates" front, things finally seem to be
calming down.
- One important newcomer is git-pack-redundant. It is still in
"pu" not because I doubt what it does is useful, but simply
because I have not had a chance to study how it does its
thing. I expect to fully merge it into "master" before 1.0
happens.
- Among my own toys in the "pu" branch:
- Determination of merge base for Octopus merge was quite
pessimistic, and a proposed fix is in there; since I will
be regularly and frequently doing Octopus merges, I'll soon
know if this change breaks things; otherwise it will
graduate to "master" shortly.
- merge-base computation done by show-branch was a bit loose
compared to the real merge-base, as pointed out by Linus on
the list, although it does not seem to matter too much in
practice. Also I plan to look into merge-base to see if I
can fix the horizon effect cheaply but that work has not
started yet (it is triggered by fairly pathological case).
- I got tired of not being able to get the committer date
(except the raw format which is unreadable) out of git-log,
and added --pretty=fuller format. This should not break
people's existing setup, so I expect it to move to "master"
soon, maybe with a name change if somebody can suggest a
better name for it.
- Change merge-one-file to handle the case where two sides
add the same path differently. Instead of punting, try to
do two-file merge from both sides. This _might_ turn out
to be useful, but I do not know yet, so it won't graduate
to "master" unless somebody convinces me (and the
community) that it is useful in some use-case scenario.
- Add git-lost+found. Currently the implementation stores
found refs under .git/lost+found/{commit,other}
directories, but writing out their object names to the
standard output and let the users decide what to do with
them was suggested on the list by Daniel, which makes sense
as well. There are pros and cons so until we know if it is
useful and if so in what form, it will not come out of "pu"
branch.
- I do not consider either git-shallow-pack and git-changes
"master" material. The former is a hack to create
deliberately broken repository. The latter is supporting a
wrong workflow, as Linus described the other day. You can
temporarily fetch what you want to compare into local
repository and run git-log or git-whatchanged normally.
Oh, and we will not be moving things out of /usr/bin/ during 1.0
timeframe.
[Footnote]
*1* If for whatever reason you would prefer to keep using the
'resolve' strategy as before when you run 'git-pull', you can
either do 'git-pull -s resolve <remote> <refspec>...' on the
command line, or add the following in your .git/config file:
[pull]
twohead = resolve
On the other hand, if you like to try resolve and then
recursive, you can have this instead (the order does matter, the
first one is tried first):
[pull]
twohead = resolve
twohead = recursive
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Ben Clifford @ 2005-11-10 6:57 UTC (permalink / raw)
To: Petr Baudis, Nikolai Weibull; +Cc: Blaisorblade, Git Mailing List
In-Reply-To: <20051109222338.GK16061@pasky.or.cz>
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
> Besides, it would be probably best to just autogenerate the
> auto-completion code - the usage information in Cogito is supposed
> to be
> 100% consistent and correct, so it should be a reliable source for
> that.
>
>
>
>
Maybe reliable and consistent but I think that info would need a bit
of augmentation to use for specifying autocompletion - for example,
in the case of:
> Usage: cg-branch-add BRANCH_NAME LOCATION
BRANCH_NAME should *not* exist so it doesn't make sense to
autocomplete from the branch list, but in the case of:
> Usage: cg-fetch [-f] [-v] [BRANCH_NAME]
BRANCH_NAME *must* exist so it makes sense to autocomplete from the
branch list.
The amount of augmentation is probably not too much - probably
sufficient to specify for each parameter a completion-source(s)
(heads, branches, filenames, blah) that doesn't get displayed in --
help. But this is more information to maintain and get out of date...
I wonder if Nikolai has had thoughts about that for zsh completion?
Hopefully if anything gets added, it would be useful for both zsh and
bash
(I confess to having pretty much no idea how zsh completion works...)
Ben
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
My email is high latency but best way to contact me. Alternatively,
SMS numbers at above URL.
^ permalink raw reply
* Re: Check for differents trees
From: Marco Costalba @ 2005-11-10 6:57 UTC (permalink / raw)
To: junkio; +Cc: git
Junio C Hamano wrote:
>Marco Costalba <mcostalba@yahoo.it> writes:
>
>> as you said, the speed is almost the same but your way is clearly better.
>
>
>How often do you do this --diff-filter=AD and why?
>
>If it is a common enough operation, we could add a specific hack
>to stop feeding the diff machinery with unwanted kind of changes
>when diff-filter is set and none of -B/-C/-M are used. That
>_might_ speed things up for you.
>
Sorry for late answer but I was off line a few days.
QGit has a tree viewer now. Tree view is updated when user browses through revisions. Loading the
file names of a given tree, although only for the open directories, is an expensive operation. So
qgit checks for different files anytime the user selects a new revision and the tree viewer is
open, I use this test to skip tree reloading if trees have the same files.
I have made some speed test on Linux tree with
git-diff-tree -r --name-status --diff-filter=AD sha1 sha2
On my box it takes from 50-100ms for near revisions to almost 2 seconds when you select a new
revision very far from current one. Add to this the fact that in distant revs case there is a high
probability that the trees are found different, so you need also to reload the tree at the end,
adding extra time before GUI update.
So definitely, It will be great to keep tree browsing snappy. I speak for qgit, but I think any
git viewer that adds tree browsing feature should benefit from this change.
Marco
P.S: By the way, if I understand correctly, what you propone is a different behavior of
--diff-filter=AD. Not to filter for AD, but to find first match of AD. Because of this, IMHO
should be better to have a --first-match=AD flag or, better idea, to use --max-count option (from
git-rev-list) togheter with --diff-filter and have something like:
git-diff-tree -r --name-status --diff-filter=AD --max-count=1 sha1 sha2
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
^ permalink raw reply
* Re: Check for differents trees
From: Marco Costalba @ 2005-11-10 6:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>Marco Costalba <mcostalba@yahoo.it> writes:
>
>> as you said, the speed is almost the same but your way is clearly better.
>
>
>How often do you do this --diff-filter=AD and why?
>
>If it is a common enough operation, we could add a specific hack
>to stop feeding the diff machinery with unwanted kind of changes
>when diff-filter is set and none of -B/-C/-M are used. That
>_might_ speed things up for you.
>
Sorry for late answer byt I was off line a few days.
Thanks, It will be great.
I have impemented a tree viewer for qgit. Tree view is updated when user browses through
revisions. Loading the file names of a given tree, altough only for the open directories, is an
expensive operation. So I check for different files anytime the user select a new revision and
the tree viewer is open, I use this test to skip tree reloading if trees have the same files.
I have made some speed test with
git-diff-tree -r --name-status --diff-filter=AD sha1 sha2
Marco
__________________________________
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
^ permalink raw reply
* [PATCH] Add --pretty=fuller
From: Junio C Hamano @ 2005-11-10 6:16 UTC (permalink / raw)
To: git
git log without --pretty showed author and author-date, while
with --pretty=full showed author and committer but no dates.
The new formatting option, --pretty=fuller, shows both name and
timestamp for author and committer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* again, likes, dislikes, don't-cares?
commit.c | 37 ++++++++++++++++++++++++++++++-------
commit.h | 1 +
2 files changed, 31 insertions(+), 7 deletions(-)
applies-to: 6466c53ae80cddbb581c5fdb2332f9321fade867
2155be5980310bac027d4719458e9f5d5975c334
diff --git a/commit.c b/commit.c
index a8c9bfc..534c03e 100644
--- a/commit.c
+++ b/commit.c
@@ -34,6 +34,8 @@ enum cmit_fmt get_commit_format(const ch
return CMIT_FMT_SHORT;
if (!strcmp(arg, "=full"))
return CMIT_FMT_FULL;
+ if (!strcmp(arg, "=fuller"))
+ return CMIT_FMT_FULLER;
if (!strcmp(arg, "=oneline"))
return CMIT_FMT_ONELINE;
die("invalid --pretty format");
@@ -361,6 +363,7 @@ static int add_user_info(const char *wha
int namelen;
unsigned long time;
int tz, ret;
+ const char *filler = " ";
if (fmt == CMIT_FMT_ONELINE)
return 0;
@@ -371,9 +374,20 @@ static int add_user_info(const char *wha
time = strtoul(date, &date, 10);
tz = strtol(date, NULL, 10);
- ret = sprintf(buf, "%s: %.*s\n", what, namelen, line);
- if (fmt == CMIT_FMT_MEDIUM)
+ ret = sprintf(buf, "%s: %.*s%.*s\n", what,
+ (fmt == CMIT_FMT_FULLER) ? 4 : 0,
+ filler, namelen, line);
+ switch (fmt) {
+ case CMIT_FMT_MEDIUM:
ret += sprintf(buf + ret, "Date: %s\n", show_date(time, tz));
+ break;
+ case CMIT_FMT_FULLER:
+ ret += sprintf(buf + ret, "%sDate: %s\n", what, show_date(time, tz));
+ break;
+ default:
+ /* notin' */
+ break;
+ }
return ret;
}
@@ -448,12 +462,21 @@ unsigned long pretty_print_commit(enum c
die("bad parent line in commit");
offset += add_parent_info(fmt, buf + offset, line, ++parents);
}
+
+ /*
+ * MEDIUM == DEFAULT shows only author with dates.
+ * FULL shows both authors but not dates.
+ * FULLER shows both authors and dates.
+ */
if (!memcmp(line, "author ", 7))
- offset += add_user_info("Author", fmt, buf + offset, line + 7);
- if (fmt == CMIT_FMT_FULL) {
- if (!memcmp(line, "committer ", 10))
- offset += add_user_info("Commit", fmt, buf + offset, line + 10);
- }
+ offset += add_user_info("Author", fmt,
+ buf + offset,
+ line + 7);
+ if (!memcmp(line, "committer ", 10) &&
+ (fmt == CMIT_FMT_FULL || fmt == CMIT_FMT_FULLER))
+ offset += add_user_info("Commit", fmt,
+ buf + offset,
+ line + 10);
continue;
}
diff --git a/commit.h b/commit.h
index 30702ca..6738a69 100644
--- a/commit.h
+++ b/commit.h
@@ -43,6 +43,7 @@ enum cmit_fmt {
CMIT_FMT_DEFAULT = CMIT_FMT_MEDIUM,
CMIT_FMT_SHORT,
CMIT_FMT_FULL,
+ CMIT_FMT_FULLER,
CMIT_FMT_ONELINE,
};
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH] Add --no-commit-id option for git-diff-tree, use it in gitk
From: Pavel Roskin @ 2005-11-10 5:30 UTC (permalink / raw)
To: git
This patch introduces -no-commit-id option for git-diff-tree, which
suppresses commit ID output.
This option is used in gitk, to suppress empty lines after "Comments"
introduced in 8b7e5d76e836396a097bb6f61cf930ea872a7bd3. Also, the p
variable is removed where is became unused due to the same patch.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index f57c8d0..9a2947e 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -8,7 +8,7 @@ git-diff-tree - Compares the content and
SYNOPSIS
--------
-'git-diff-tree' [--stdin] [-m] [-s] [-v] [--pretty] [-t] [-r] [--root] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
+'git-diff-tree' [--stdin] [-m] [-s] [-v] [--no-commit-id] [--pretty] [-t] [-r] [--root] [<common diff options>] <tree-ish> [<tree-ish>] [<path>...]
DESCRIPTION
-----------
@@ -74,6 +74,10 @@ separated with a single space are given.
commit message. Without "=<style>", it defaults to
medium.
+--no-commit-id::
+ git-diff-tree outputs a line with the commit ID when
+ applicable. This flag suppressed the commit ID output.
+
Limiting Output
---------------
diff --git a/diff-tree.c b/diff-tree.c
index ed323d8..f2c629b 100644
--- a/diff-tree.c
+++ b/diff-tree.c
@@ -3,6 +3,7 @@
#include "commit.h"
static int show_root_diff = 0;
+static int no_commit_id = 0;
static int verbose_header = 0;
static int ignore_merges = 1;
static int read_stdin = 0;
@@ -28,7 +29,7 @@ static int call_diff_flush(void)
diff_options.output_format = saved_fmt;
return 0;
}
- if (header) {
+ if (header && !no_commit_id) {
printf("%s%c", header, diff_options.line_termination);
header = NULL;
}
@@ -231,6 +232,10 @@ int main(int argc, const char **argv)
show_root_diff = 1;
continue;
}
+ if (!strcmp(arg, "--no-commit-id")) {
+ no_commit_id = 1;
+ continue;
+ }
usage(diff_tree_usage);
}
if (diff_options.output_format == DIFF_FORMAT_PATCH)
diff --git a/gitk b/gitk
index a9d37d9..6d47139 100755
--- a/gitk
+++ b/gitk
@@ -2805,8 +2805,7 @@ proc gettreediffs {ids} {
set treepending $ids
set treediff {}
set id [lindex $ids 0]
- set p [lindex $ids 1]
- if [catch {set gdtf [open "|git-diff-tree -r $id" r]}] return
+ if [catch {set gdtf [open "|git-diff-tree --no-commit-id -r $id" r]}] return
fconfigure $gdtf -blocking 0
fileevent $gdtf readable [list gettreediffline $gdtf $ids]
}
@@ -2840,9 +2839,8 @@ proc getblobdiffs {ids} {
global difffilestart nextupdate diffinhdr treediffs
set id [lindex $ids 0]
- set p [lindex $ids 1]
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [list | git-diff-tree -r -p -C $id]
+ set cmd [list | git-diff-tree --no-commit-id -r -p -C $id]
if {[catch {set bdf [open $cmd r]} err]} {
puts "error getting diffs: $err"
return
--
Regards,
Pavel Roskin
^ permalink raw reply related
* merge-one-file: use common as base, instead of emptiness.
From: Junio C Hamano @ 2005-11-10 4:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: Jon Loeliger, git
In-Reply-To: <20051108095600.GA1431@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> I think having
>
> <<<<<
> file1
> =====
> file2
> >>>>>
>
> is an awful PITA to resolve, especially when the files actually are
> similar. Running some vimdiff (or just diff and possibly applying either
> way) on two separate files is much more convenient.
You are right.
How about something like this? This adds a specialized hackery
flag, --no-add, to git-apply, and uses it to compute common base
to be used for 2-file merge, instead of using /dev/null.
On top of the previous round.
-- >8 -- cut here -- >8 --
Unlike the previous round that merged the path added differently
in each branches using emptiness as the base, compute a common
version and use it as input to 'merge' program.
This would show the resulting (still conflicting) file left in
the working tree as:
common file contents...
<<<<<< FILENAME
version from our branch...
======
version from their branch...
>>>>>> .merge_file_XXXXXX
more common file contents...
when both sides added similar contents.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
apply.c | 11 +++++++++--
git-merge-one-file.sh | 6 ++++--
2 files changed, 13 insertions(+), 4 deletions(-)
applies-to: 75c7cdf0addfcb4df5ed093f9b57bb98432489e1
f158ab58fd3846a784805849bd9228bf060e4b2d
diff --git a/apply.c b/apply.c
index 3e53b34..7584888 100644
--- a/apply.c
+++ b/apply.c
@@ -23,6 +23,7 @@ static int numstat = 0;
static int summary = 0;
static int check = 0;
static int apply = 1;
+static int no_add = 0;
static int show_index_info = 0;
static int line_termination = '\n';
static const char apply_usage[] =
@@ -1099,8 +1100,10 @@ static int apply_one_fragment(struct buf
break;
/* Fall-through for ' ' */
case '+':
- memcpy(new + newsize, patch + 1, plen);
- newsize += plen;
+ if (*patch != '+' || !no_add) {
+ memcpy(new + newsize, patch + 1, plen);
+ newsize += plen;
+ }
break;
case '@': case '\\':
/* Ignore it, we already handled it */
@@ -1697,6 +1700,10 @@ int main(int argc, char **argv)
excludes = x;
continue;
}
+ if (!strcmp(arg, "--no-add")) {
+ no_add = 1;
+ continue;
+ }
if (!strcmp(arg, "--stat")) {
apply = 0;
diffstat = 1;
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 32e17cb..d9ee458 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -57,18 +57,20 @@ case "${1:-.}${2:-.}${3:-.}" in
# Modified in both, but differently.
#
"$1$2$3" | ".$2$3")
+ src2=`git-unpack-file $3`
case "$1" in
'')
echo "Added $4 in both, but differently."
+ # This extracts OUR file in $orig, and uses git-apply to
+ # remove lines that are unique to ours.
orig=`git-unpack-file $2`
- : >$orig
+ diff -u -La/$orig -Lb/$orig $orig $src2 | git-apply --no-add
;;
*)
echo "Auto-merging $4."
orig=`git-unpack-file $1`
;;
esac
- src2=`git-unpack-file $3`
# We reset the index to the first branch, making
# git-diff-file useful
---
0.99.9.GIT
^ permalink raw reply related
* Re: Expected Behavior?
From: Martin Langhoff @ 2005-11-10 2:47 UTC (permalink / raw)
To: Petr Baudis; +Cc: Fredrik Kuivinen, Junio C Hamano, Jon Loeliger, git
In-Reply-To: <20051109234925.GL30496@pasky.or.cz>
On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> But that's something different that I'm talking about. :-)
Ack! Sorry about that!
> Yes. My longer plan is to use the strategy resolvers as well, but my
> TODO list is big... And I don't perceive this as a critical thing (the
> standard strategy seems to work well enough), although I would like to
> see this before 1.0.
Fair enough. If you can outline how the interaction between cg-merge
and cg-commit are expected to work, I'll try and find some time for
that.
> > Right now I am seeing some slightly abnormal things (*) in how some
> > our our merges are going, so I' ll have to roll up my sleeves at some
> > point and try and figure out what's going on. And as I look into
> > cg-merge and cg-Xmergefile, not many eyes have been through it...
>
> At least this is the one area of Cogito that has at least a bit
> reasonable automated testing suite. ;-)
The good news is that git-merge is doing almost the same. Posted separately...
martin
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Ben Clifford @ 2005-11-10 2:03 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <20051109222338.GK16061@pasky.or.cz>
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
> Dear diary, on Tue, Nov 08, 2005 at 11:16:28AM CET, I got a letter
> where Ben Clifford <benc@hawaga.org.uk> told me that...
>
>> I've added some stuff to this to do a few cogito, gitk and (one) git
>> completions, split into different files. I thought I might as well
>> toss what I have out for anyone interested to play with.
btw, I got the repository for this working (it was working all along,
it seems)...
cg clone http://www.hawaga.org.uk/gitcompletion.git
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
^ permalink raw reply
* Re: latest stg/git commandline completions code
From: Ben Clifford @ 2005-11-10 1:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List, Blaisorblade
In-Reply-To: <20051109222338.GK16061@pasky.or.cz>
On 10 Nov 2005, at 09:23, Petr Baudis wrote:
>
> Nice, I would like to add cg completion to Cogito's contrib/ -
> could you
> please add some header to it with (c) information and stuff? (And make
> it available somewhere just as a plain file.)
OK, will do.
> Besides, it would be probably best to just autogenerate the
> auto-completion code - the usage information in Cogito is supposed
> to be
> 100% consistent and correct, so it should be a reliable source for
> that.
yeah, I was thinking about that this morning -- maybe I'll be in the
mood to implement...
There are a few small common functions that are used by all the git
completions, though. I suppose for going into cogito's contrib/ I
should include them directly in cogito completion code, but that
seems a little messy, as it would be nice to keep them in-sync with
what is used in the other completion files. hmm.
Ben
--
Ben ベン Бэн
http://www.hawaga.org.uk/ben/
^ permalink raw reply
* CVSps fixed; git-cvsimport works, too
From: Chris Shoemaker @ 2005-11-10 1:41 UTC (permalink / raw)
To: git; +Cc: cvsps, David Mansfield, Martin Langhoff
In-Reply-To: <20051109222634.GA19209@pe.Belkin>
On Wed, Nov 09, 2005 at 05:26:34PM -0500, Chris Shoemaker wrote:
> I could cut git-cvsimport some slack for failing to infer that file
> 'b' is also on the 'dev' branch, since I learned how hard that is when
> I taught CVSps to make that inference. But completely missing a
> branch and all files added to it is not good.
Ok. Whew, I'm glad to report that I was mistaken. git-cvsimport
performs beautifully when given the new CVSps output. Sorry for the
noise.
I'll change this then to an announcement that with that CVSps patch,
CVSps produces more accurate branch ancestry, and git-cvsimport can
correctly reproduce branch-of-a-branch histories.
On a related note, the new '-P' option doesn't behave exactly as I
expected. You must provide the _full_ pathname to the input file
CVSps file. If that's not a bug, it should at least be documented.
-chris
^ permalink raw reply
* Re: Cogito: cg-clone doesn't like packed tag objects
From: Nick Hengeveld @ 2005-11-10 1:01 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20051109234405.GK30496@pasky.or.cz>
On Thu, Nov 10, 2005 at 12:44:05AM +0100, Petr Baudis wrote:
> Hmm. Yes, that's bad. Couldn't the HTTP pusher actually get the current
> server info, update it at the pusher's side and send it back?
Yes, although duplicating all of what update-server-info does is going
to take a while...
However, the only thing of interest to update-server-info that http-push
is able to change is a ref. It would be much more straightforward to
lock and update info/refs after a successful push; is that good enough?
The same thing could apply to objects/info/packs if/when http-push
starts sending packs.
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Strange merge conflicts against earlier merge.
From: Martin Langhoff @ 2005-11-10 0:38 UTC (permalink / raw)
To: Git Mailing List
We are working with a series of closely related heads, and merging
among them. I am sometimes finding merge conflicts that I don't think
I should be seeing. Assuming two branches, 'local' and 'remote', where
local has with remote before (*), and I have no conflicting changes in
local...
1 - pull and merge from remote. The merge touches file A, B and C
2 - on local, develop on unrelated files O,P,Q, commit
3 - pull and merge from remote. The merge touches file B, C and D. I
am sometimes seeing conflicts on file B and C, which was never touched
on local.
* - In the case i have, the ancestry before the merge is a bit
convoluted. AFAIK, this shouldn't affect us going forward. Both
branches have a common ancestor, though, and are now merging often
from remote to local.
We are using cogito for this, although on step 3 I have also tested
with git-merge.sh and I get the same result. It could still be a
problem related to how the merge on step 1 is recording the merge.
For an example, clone
http://locke.catalyst.net.nz/git/moodle.git#mdl-artena-tairawhiti and
register also the
http://locke.catalyst.net.nz/git/moodle.git#mdl-local branch. Create
two heads:
master: 214e6374d49e6d014f0ba6f159d585a3fe468909
remote: 05059be73c9e09e22b98bc796be35c595e551ed6
On git-merge 'testing merge' master remote you'll see conflicts over
mod/quiz/editlib.php -- doing the same with cg-merge gets an
additional conflict on mod/quiz/export.php. Neither of those files
were ever modified on local -- however, both merges brought in changes
to the same lines of code.
I suspect this is because the merge itself is being considered a
commit on the local branch. Fair enough -- git has no way of ensuring
that I haven't slipped in a few changes of mine in the merge. OTOH,
it's pretty unexpected to see this on files that are not one char
different from the 'remote' branch. Am I doing something wrong?
cheers,
martin
^ permalink raw reply
* Re: Regarding: git-lost+found
From: Daniel Barkalow @ 2005-11-10 0:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtjh8kxu.fsf@assigned-by-dhcp.cox.net>
On Wed, 9 Nov 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > Why have git-lost+found write to files at all? It seems to me easiest to
> > have the list go to standard out, and you could do "gitk `git-lost+found
> > -t commit`" to see lost commits, and reconnect them as desired. (Making up
> > command line syntax for listing only the commits.)
>
> That is certainly cleaner. The only downside is fsck-objects
> that lost+found uses tends to be expensive operation, and what
> you would want to do with the information may be more than just
> use it on the command line of gitk. But in any case the user
> could store git-lost+found output in a file to do whatever she
> wants, so it may not matter.
Actually, my next suggestion would be to have gitk able to write
hashes as refs, so that, having put it on the gitk command line, you could
then do the things you want from there.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: HTTP redirection with git-clone/git-fetch ?
From: Nick Hengeveld @ 2005-11-10 0:24 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511092331.36421.Josef.Weidendorfer@gmx.de>
On Wed, Nov 09, 2005 at 11:31:36PM +0100, Josef Weidendorfer wrote:
> This seems because git-fetch should understand redirections, too.
> I am not familiar to the curl API. So perhaps another one can try to
> fix this?
This should fix it, although it still tries every GET with the original
URL which is a bit inefficient.
Configure HTTP fetch to follow redirects
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
---
git-fetch.sh | 2 +-
http-fetch.c | 2 ++
2 files changed, 3 insertions(+), 1 deletions(-)
applies-to: bc694e972ad9e82f65359788db6ef788078a975f
deb8d58781a60d4611651478c5b08739edf981b7
diff --git a/git-fetch.sh b/git-fetch.sh
index 31e5f4c..8564cbf 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -230,7 +230,7 @@ do
$u =~ s{([^-a-zA-Z0-9/.])}{sprintf"%%%02x",ord($1)}eg;
print "$u";
' "$remote_name")
- head=$(curl -nsf $curl_extra_args "$remote/$remote_name_quoted") &&
+ head=$(curl -nsfL $curl_extra_args "$remote/$remote_name_quoted") &&
expr "$head" : "$_x40\$" >/dev/null ||
die "Failed to fetch $remote_name from $remote"
echo >&2 Fetching "$remote_name from $remote" using http
diff --git a/http-fetch.c b/http-fetch.c
index ea8af1b..28d225c 100644
--- a/http-fetch.c
+++ b/http-fetch.c
@@ -269,6 +269,8 @@ static CURL* get_curl_handle(void)
curl_low_speed_time);
}
+ curl_easy_setopt(result, CURLOPT_FOLLOWLOCATION, 1);
+
return result;
}
---
0.99.9.GIT
^ permalink raw reply related
* Do I misunderstand cg-merge --squash option
From: Alan Chandler @ 2005-11-10 0:25 UTC (permalink / raw)
To: git
I am trying to take my current development repository which has several
hundred commits in it as I was developing my application and make a
simplified branch for pushing to my public repository.
I basically created a new branch (public) from the tag at the point where I
started the repository.
git-checkout -b public initial_commit
I then did a merge
cg-merge --squash v1.0
This seemed to work fine (although it had trouble prompting me with an open
editor to edit the commit message)
But I don't know how to move forward and merge in changes after my v1.0 tag.
Any attempt to merge anything else into this "public" branch seems to throw
up what appears to be merge conflict, but I can't see why - when I look at
the results one side has extra lines, but there is no other overlap.
--
Alan Chandler
http://www.chandlerfamily.org.uk
Open Source. It's the difference between trust and antitrust.
^ permalink raw reply
* Re: [PATCH 0/4] Add git-pack-intersect
From: Junio C Hamano @ 2005-11-10 0:15 UTC (permalink / raw)
To: git
In-Reply-To: <43728523.1040209@etek.chalmers.se>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=iso-2022-jp-2, Size: 924 bytes --]
Lukas Sandstr^[.A^[Nvm <lukass@etek.chalmers.se> writes:
> Perhaps if git-daemon ever does caching of packfiles, removing the smaller
> packfiles might not be optimal.
Ah, that reminds me of something.
I did not advertise it too much, but you can put a prepackaged
packs in $GIT_DIR/pack-cache/ and it is used when upload-pack
notices it is creating that exact pack.
This is useless for ordinary repository, but can be useful for
historical repositories whose heads/tags never change (e.g. the
Linux kernel repository resurrected from bkcvs). There you
could:
$ git repack -a -d
$ ln $GIT_DIR/objects/pack/pack-* $GIT_DIR/pack-cache/.
and a clone request would feed the pack, without regenerating
the pack data from scratch. upload-pack still reads, sorts and
computes SHA1 hash of the list of objects to find the pack name,
but that is a fairly quick operation, compared to the rest of
the pack generation process.
^ 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