* Re: [RFC PATCH] Add support for figuring out where in the git archive we are
From: Daniel Barkalow @ 2005-08-17 0:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508161536390.3553@g5.osdl.org>
On Tue, 16 Aug 2005, Linus Torvalds wrote:
> If you use the GIT_DIR environment variable approach, it assumes that all
> filenames you give it are absolute and acts the way it always did before.
>
> Comments? Like? Dislike?
I'm all in favor, at least in the general case. I suspect there'll be some
things where we have to discuss the behavior, but we can argue that when
it comes up.
I think, slightly before 1.0, we should sort the library functions into a
new set of object files with matching header files, because "setup" is not
really distinctive, and there's at least one duplicate implementation
(the ssh subprocess code in your connect.c is the same as my rsh.c in what
it does, although yours uses two pipes and mine uses a socket).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* gitk with hyperspace support
From: Paul Mackerras @ 2005-08-17 0:21 UTC (permalink / raw)
To: git
I have been trying a new approach to drawing the commit graph in gitk.
This involves sending a lot of the really long lines into
"hyperspace", by terminating them with an arrow pointing down when the
graph gets too wide, and then reintroducing them later with an arrow
pointing up, as though they had used a warp drive to dive beneath the
screen (into the mysterious 3rd dimension :) and then reappear later.
The result is that the graph stays at a reasonable width and doesn't
need to be compressed.
My reasoning is that it is the local short-range connections which are
interesting and informative. The long-range connections aren't really
visually informative; if you want to know about the long-range
connections, the parent and child lists in the details pane are much
more useful.
I would like to get some feedback about what people think of the
visual effect of this new approach, and in particular whether having
the lines jump into hyperspace loses information that people find
useful. The new version is at:
http://ozlabs.org/~paulus/gitk/gitk.hs
If the reaction is positive I'll check this into my gitk.git
repository.
Thanks,
Paul.
^ permalink raw reply
* Re: [RFC PATCH] Add support for figuring out where in the git archive we are
From: Junio C Hamano @ 2005-08-17 0:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508161655460.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Do you want to take the current patch (which buys you very little because
> not a lot of stuff has been set up to deal with it, but is the basis for
> all future work anyway) or do you want me to polish it up a bit and
> re-submit the whole thing?
The developement history would look nicer if you did the latter,
but I am easy and can go either way.
> I'd do at least the "git-diff-tree" part and the "./" and "../" handling,
> and convert at least the "git diff" thing to the new world order and away
> from git-sh-setup-script?
Sounds like fun.
^ permalink raw reply
* Re: sending changesets from the middle of a git tree
From: Wolfgang Denk @ 2005-08-17 0:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis, Linus Torvalds
In-Reply-To: <7vfytc9dzw.fsf@assigned-by-dhcp.cox.net>
Hello,
in message <7vfytc9dzw.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> This is the kind of situation I used to have all the time when
> Linus was the maintainer and I was a contributor, when you look
> at "master" branch being the "maintainer" branch, and "pu"
> branch being the "contributor" branch. Your work started at the
...
> your changes) "pu" rather than merge. So I ran "git rebase":
>
> $ git checkout pu
> $ git rebase master pu
How do you handle conflicts in such a situation?
For example, I get:
-> git rebase master testing-NAND
67a002cbe2b2850d76d797e679bc290a76666df6
patching file common/cmd_nand.c
Hunk #2 FAILED at 18.
Hunk #3 succeeded at 335 (offset 1 line).
1 out of 4 hunks FAILED -- saving rejects to file common/cmd_nand.c.rej
external diff died, stopping at common/cmd_nand.c.
Some commits could not be rebased, check by hand:
67a002cbe2b2850d76d797e679bc290a76666df6
OK, I can edit the file to resolve the conflicts. But what do I do
then to continue?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
...when fits of creativity run strong, more than one programmer or
writer has been known to abandon the desktop for the more spacious
floor. - Fred Brooks, Jr.
^ permalink raw reply
* Re: [RFC PATCH] Add support for figuring out where in the git archive we are
From: Linus Torvalds @ 2005-08-17 0:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vll315u3w.fsf@assigned-by-dhcp.cox.net>
On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> Comments: Wouldn't that mean git-*-scripts would not benefit from this
> because git-sh-setup would set GIT_DIR for you even if
> you don't?
As it stands now, yes. But the point being that if people like this, then
I'll just change the git-sh-setup-script accordingly. For example, once
git-diff-tree also does the same thing, then "git-diff-script" would have
no reason left to even call the current git-sh-setup-script at all, since
the git-diff-* commands would basically do the setup _and_ report the
errors that git-sh-setup-script does now.
> If you can do "cd drivers && git-diff-files ../net"
> that would be very useful.
I don't do that right now, but it's actually very easy to do in the
setup_git_directory() function. It falls out very simply there - both the
"./" and the "../" prefix would make tons of sense to handle there.
Do you want to take the current patch (which buys you very little because
not a lot of stuff has been set up to deal with it, but is the basis for
all future work anyway) or do you want me to polish it up a bit and
re-submit the whole thing?
I'd do at least the "git-diff-tree" part and the "./" and "../" handling,
and convert at least the "git diff" thing to the new world order and away
from git-sh-setup-script?
Linus
^ permalink raw reply
* Re: [RFC PATCH] Add support for figuring out where in the git archive we are
From: Junio C Hamano @ 2005-08-16 23:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508161536390.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> If you use the GIT_DIR environment variable approach, it assumes that all
> filenames you give it are absolute and acts the way it always did before.
> Comments? Like? Dislike?
Comments: Wouldn't that mean git-*-scripts would not benefit from this
because git-sh-setup would set GIT_DIR for you even if
you don't?
Even if you do not have to do discovery, it may make
more sense to do the pathname translation (making them
all relative to the project root) for consistency.
If you can do "cd drivers && git-diff-files ../net"
that would be very useful. More realistically, people
would very much appreciate if stripping the leading ./ in
"find . -type f -print0 | xargs -0 git-blah-command".
Like: Yes, you finally saw the light ;-).
Dislike: I believe I was one of the original proponent for this
kind of thing, so no.
^ permalink raw reply
* Re: gitweb - option to disable rename detection
From: Yasushi SHOJI @ 2005-08-16 23:14 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508151542290.3553@g5.osdl.org>
At Mon, 15 Aug 2005 15:43:26 -0700 (PDT),
Linus Torvalds wrote:
>
> On Tue, 16 Aug 2005, Yasushi SHOJI wrote:
> >
> > > Instead of disabling it entirely, how about just having some limit on it?
> >
> > ah, that's a good idea. here is a quick and dirty patch.
>
> This makes it somewhat more expensive.
yes. but much cheaper than OOM ;P
> - I was thinking about disabling it
> in git-diff-tree, since the rename logic already knows how many
> new/deleted files there are.
I'll leave this feature for homework. I'll work on
prepare_temp_file() first since it seems to fix my problem.
regards,
--
yashi
^ permalink raw reply
* Re: [RFC PATCH] Add support for figuring out where in the git archive we are
From: Yasushi SHOJI @ 2005-08-16 23:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508161536390.3553@g5.osdl.org>
At Tue, 16 Aug 2005 15:45:35 -0700 (PDT),
Linus Torvalds wrote:
>
> This is really partly a serious patch, but also just a query whether
> people would want git to work in subdirectories, not just the top-level
> directory.
>
> So you can be in linux/drivers, and if you do a
>
> git-diff-files -p char
>
> then it will automatically be turned into the full pathname, and do the
> right thing (ie do a diff of drivers/char only).
I've had missed this feature a lot, since quilt has been working this
way. now I can close just-for-git terminal.(tm)
regards,
--
yashi
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Carl Baldwin @ 2005-08-16 23:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carl Baldwin, git
In-Reply-To: <7vll318u8b.fsf@assigned-by-dhcp.cox.net>
On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote:
> And presumably you have .git/branches/myremotebranch file that
> says something like "master.kernel.org:/pub/scm/git/git.git".
> Or should the last line of relationships file be spelled just
> push:master:ko-master?
Oops, I did intend to add just that to .git/branches/myremotebranch.
> > % cat .git/remotes/ko
> > push: master:ko-master pu:ko-pu rc:ko-rc
> > pull: ko-master:master ko-pu:pu ko-rc:rc
> >
> > I might argue that this is now a job for a porcelain script or
> > something.
>
> Probably.
>
> My primary interest in discussing this is to see Porcelain folks
> agree on what notation and semantics to use, and probably set an
> example by having the minimum base in the barebone Porcelain.
This sounds good.
> Personally I think there are two kinds of patch-flow: one that
> is pretty much static that can easily be described with
> something like your relationships notation, and ad-hoc one that
> I think should not automatically contaminate the established
> static flow your relationships notation nicely describes. The
> corporate world may put disproportional stress on the importance
> of the former, but my feeling is that ad-hoc patch-flow that is
> outside your usual static patch-flow is just as important; see
> Documentation/howto/using-topic-branches.txt for why.
I don't doubt the utility of these topic branches. In fact, I think it
what he's doing with this is great. This is exactly the kind of thing
the 'relationships' could help out with.
As he creates branches from existing branches, pushes, pulls and merges
between them the relationships files would maintain a record of this.
Let's say, for example, he made a change on speed-up-spinlocks and
merged it to test. Later, a bug is found and he fixes the bug on the
speed-up-spinlocks branch. Now, a script could run using the
relationships files that could immediately tell that the test branch is
behind the speed-up-spinlocks branch and that they should be merged.
For someone who has a lot of different things to do this will be
valuable.
I would leave maintenance of any static work flows up to the porcelains.
If a project chose to use some sort of static flow then it can simply
populate the relationships files to help drive pushing and pulling if
some rogue developer were to use git alone or some other porcelain (thus
maintaining compatibility between porcelains). If a porcelain wanted to
be very strict about adherance to a static flow then checking the
relationships could tell if something 'bad' has been done outside of
that porcelain.
I hope I'm being clear. Please let me know if something is not clear.
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
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* [RFC PATCH] Add support for figuring out where in the git archive we are
From: Linus Torvalds @ 2005-08-16 22:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This does only "git-diff-cache" and "git-diff-files", but the concept
should work for any command that uses the working tree.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is really partly a serious patch, but also just a query whether
people would want git to work in subdirectories, not just the top-level
directory.
So you can be in linux/drivers, and if you do a
git-diff-files -p char
then it will automatically be turned into the full pathname, and do the
right thing (ie do a diff of drivers/char only).
I didn't want to do it originally, but that was largely a complexity
issue, and an issue of there being many more things up in the air at that
time. Now, things have calmed down a bit, the interfaces are fairly
stable, and it turns out to be not that difficult to just walk up the
chain of directories until we hit the one that has the ".git" directory in
it.
I only converted "git-diff-files" and "git-diff-cache" to do this, because
so far it's a technology demo. And the "git-diff-script" file (and the
git-sh-setup-script in particular) does _not_ accept this "automatically
figure out where we are" thing, so it's really only the native git diff
commands that do it.
But if people think it's a good idea, I can pretty trivially convert the
rest. It's done in a way that makes it very easy to convert programs to
take advantage of the auto-git-directory-finding thing.
If you use the GIT_DIR environment variable approach, it assumes that all
filenames you give it are absolute and acts the way it always did before.
Comments? Like? Dislike?
Linus
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -97,7 +97,7 @@ LIB_H=cache.h object.h blob.h tree.h com
LIB_OBJS=read-cache.o sha1_file.o usage.o object.o commit.o tree.o blob.o \
tag.o date.o index.o diff-delta.o patch-delta.o entry.o path.o \
refs.o csum-file.o pack-check.o pkt-line.o connect.o ident.o \
- sha1_name.o
+ sha1_name.o setup.o
LIB_H += rev-cache.h
LIB_OBJS += rev-cache.o
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -140,6 +140,8 @@ extern char *get_graft_file(void);
#define ALTERNATE_DB_ENVIRONMENT "GIT_ALTERNATE_OBJECT_DIRECTORIES"
+extern char **setup_git_directory(char **pathspec);
+
#define alloc_nr(x) (((x)+16)*3/2)
/* Initialize and use the cache information */
diff --git a/diff-cache.c b/diff-cache.c
--- a/diff-cache.c
+++ b/diff-cache.c
@@ -179,15 +179,12 @@ int main(int argc, const char **argv)
int allow_options = 1;
int i;
- read_cache();
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (!allow_options || *arg != '-') {
- if (tree_name) {
- pathspec = argv + i;
+ if (tree_name)
break;
- }
tree_name = arg;
continue;
}
@@ -265,12 +262,16 @@ int main(int argc, const char **argv)
usage(diff_cache_usage);
}
+ pathspec = setup_git_directory(argv + i);
+
if (find_copies_harder && detect_rename != DIFF_DETECT_COPY)
usage(diff_cache_usage);
if (!tree_name || get_sha1(tree_name, sha1))
usage(diff_cache_usage);
+ read_cache();
+
/* The rest is for paths restriction. */
diff_setup(diff_setup_opt);
diff --git a/diff-files.c b/diff-files.c
--- a/diff-files.c
+++ b/diff-files.c
@@ -45,8 +45,7 @@ int main(int argc, const char **argv)
{
static const unsigned char null_sha1[20] = { 0, };
const char **pathspec;
- int entries = read_cache();
- int i;
+ int entries, i;
while (1 < argc && argv[1][0] == '-') {
if (!strcmp(argv[1], "-p") || !strcmp(argv[1], "-u"))
@@ -95,8 +94,9 @@ int main(int argc, const char **argv)
argv++; argc--;
}
- /* Do we have a pathspec? */
- pathspec = (argc > 1) ? argv + 1 : NULL;
+ /* Find the directory, and set up the pathspec */
+ pathspec = setup_git_directory(argv + 1);
+ entries = read_cache();
if (find_copies_harder && detect_rename != DIFF_DETECT_COPY)
usage(diff_files_usage);
diff --git a/setup.c b/setup.c
new file mode 100644
--- /dev/null
+++ b/setup.c
@@ -0,0 +1,66 @@
+#include "cache.h"
+
+char **setup_git_directory(char **pathspec)
+{
+ static char *spec[2], **p;
+ static char cwd[PATH_MAX+1];
+ int len, offset;
+
+ /*
+ * If GIT_DIR is set explicitly, we're not going
+ * to do any discovery
+ */
+ if (gitenv(GIT_DIR_ENVIRONMENT))
+ return *pathspec ? pathspec : NULL;
+
+ if (!getcwd(cwd, sizeof(cwd)) || cwd[0] != '/')
+ die("Unable to read current working directory");
+
+ offset = len = strlen(cwd);
+ for (;;) {
+ /*
+ * We always want to see a .git/HEAD and a .git/refs/
+ * subdirectory
+ */
+ if (!access(".git/HEAD", R_OK) && !access(".git/refs/", X_OK)) {
+ /*
+ * Then we need either a GIT_OBJECT_DIRECTORY define
+ * or a .git/objects/ directory
+ */
+ if (gitenv(DB_ENVIRONMENT) || !access(".git/objects/", X_OK))
+ break;
+ }
+ chdir("..");
+ do {
+ if (!offset)
+ die("Not a git repository");
+ } while (cwd[--offset] != '/');
+ }
+
+ if (offset == len)
+ return *pathspec ? pathspec : NULL;
+
+ /* Make "offset" point to past the '/', and add a '/' at the end */
+ offset++;
+ cwd[len++] = '/';
+ cwd[len] = 0;
+
+ /* An empty pathspec gets turned into the directory we were in */
+ if (!*pathspec) {
+ spec[0] = cwd + offset;
+ spec[1] = NULL;
+ return spec;
+ }
+
+ /* Otherwise we have to re-write the entries.. */
+ p = pathspec;
+ do {
+ int speclen = strlen(*p);
+ char *n = xmalloc(speclen + len - offset + 1);
+ memcpy(n, cwd + offset, len - offset);
+ memcpy(n + len - offset, *p, speclen+1);
+ *p = n;
+ } while (*++p);
+ return pathspec;
+}
+
^ permalink raw reply
* FUNKY tags.
From: Dave Jones @ 2005-08-16 22:43 UTC (permalink / raw)
To: git
I just tried a cvs->git conversion using the git-cvsimport-script
and cvsps flagged a bunch of tags as **FUNKY**
I've no idea what I did when I tagged those trees, but according
to a google search, cvsps does that when it find patchsets which
are chronologically (and thus by patchset id) earlier than the tag,
but are tagwise after. Spooky.
I looked the tree over with gitk, and it seemed fine around those tags,
so I'm wondering what value there is in preserving this info, and
whether we should remove it at cvsimport time somehow. Comments?
Dave
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Daniel Barkalow @ 2005-08-16 22:45 UTC (permalink / raw)
To: Marco Costalba; +Cc: martin.langhoff, git
In-Reply-To: <20050816220923.42545.qmail@web26301.mail.ukl.yahoo.com>
On Tue, 16 Aug 2005, Marco Costalba wrote:
> Martin Langhoff wrote:
>
> >>From what I understand, you'll want the StGIT infrastructure. If you
> >use git/cogito, there is an underlying assumption that you'll want
> >all the patches merged across, and a simple cg-update will bring in
> >all the pending stuff.
> >
>
> My concerns are both metodologicals and practical:
>
> 1) Method: To use the 'free patching workflow' on git is something foreseen in
> git design, something coherent with the fork + develop + merge cycle that it
> seems, at least to me, THE way git is meant to be used. Or it is stretching
> the possibility of the tool to something technically allowed but not suggested.
Patches are definitely meant to be part of how git is used; they are the
primary way of getting clean history out of messy history (that is, saving
a content change while discarding some history that isn't applicable).
There's relatively little support in git itself, but that's because the
point is to go outside the system's tracking. There have been various
discussions of more explicit support, and nobody's been able to come up
with a need.
> 2) Practical: The round trip git-format-patch + git-applymbox is the logical and
> natural way to reach this goal or, also in this case, I intend to stretch some tools,
> designed for one thing, for something else?
I'd guess that git-diff-tree + git-apply (without the rest of the
scripting) would be more effective when you're not doing anything with the
intermediate files, since it saves doing a bunch of formatting and
parsing.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] git-format-patch fix
From: Junio C Hamano @ 2005-08-16 22:31 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <20050816214707.6842.qmail@web26302.mail.ukl.yahoo.com>
Introduces --keep-subjects flag to tell it not to munge the
first line of the commit message. Running "git applymbox" on
the output from "git format-patch -m -k" would preserve the
original commit information better this way.
At the same time, prefix Subject: on the first line of the
commit, to help people cut©.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Marco Costalba <mcostalba@yahoo.it> writes:
> The extra '[PATCH]' in the subject was introduced by git-format-patch --mbox.
> Perhaps I have made something wrong.
No, sorry, I noticed that myself after I wrote that message.
There should be an option to tell --mbox format not do that. My
thinko.
Adding [PATCH] on the subject line even in --mbox format should
also be supported for people who run "git send-email" to send
things out. So there is a new option '-k' to keep the original
subject line for the "cherry-pick" operation.
This also changes it to always prefix "Subject: ". I think it
makes the output look consistent, even without --mbox option,
and would help people cutting and pasting the Subject line,
depending on their MUAs (it would certainly help me), but at the
same time it may make cutting and pasting cumbersome for some
other people. Opinions? Objections?
------------
git-format-patch-script | 31 ++++++++++++++++++++-----------
1 files changed, 20 insertions(+), 11 deletions(-)
32128d94ab63ea65bb86cb7fa7425e51e0dfeeb0
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -6,7 +6,7 @@
. git-sh-setup-script || die "Not a git archive."
usage () {
- echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [--signoff] [-<diff options>...] upstream [ our-head ]
+ echo >&2 "usage: $0"' [-n] [-o dir] [--keep-subject] [--mbox] [--check] [--signoff] [-<diff options>...] upstream [ our-head ]
Prepare each commit with its patch since our-head forked from upstream,
one file per patch, for e-mail submission. Each output file is
@@ -44,6 +44,9 @@ do
date=t ;;
-m|--m|--mb|--mbo|--mbox)
date=t author=t mbox=t ;;
+ -k|--k|--ke|--kee|--keep|--keep-|--keep-s|--keep-su|--keep-sub|\
+ --keep-subj|--keep-subje|--keep-subjec|--keep-subject)
+ keep_subject=t ;;
-n|--n|--nu|--num|--numb|--numbe|--number|--numbere|--numbered)
numbered=t ;;
-s|--s|--si|--sig|--sign|--signo|--signof|--signoff)
@@ -64,6 +67,11 @@ do
shift
done
+case "$keep_subject$numbered" in
+tt)
+ die '--keep-subject and --numbered are incompatible.' ;;
+esac
+
revpair=
case "$#" in
2)
@@ -142,21 +150,22 @@ do
{
mailScript='
/./d
- /^$/n
- s|^\[PATCH[^]]*\] *||'
-
- case "$mbox" in
- t)
- echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
- mailScript="$mailScript"'
- s|^|Subject: [PATCH'"$num"'] |'
- ;;
+ /^$/n'
+ case "$keep_subject" in
+ t) ;;
*)
mailScript="$mailScript"'
+ s|^\[PATCH[^]]*\] *||
s|^|[PATCH'"$num"'] |'
;;
esac
-
+ mailScript="$mailScript"'
+ s|^|Subject: |'
+ case "$mbox" in
+ t)
+ echo 'From nobody Mon Sep 17 00:00:00 2001' ;# UNIX "From" line
+ ;;
+ esac
eval "$(sed -ne "$whosepatchScript" $commsg)"
test "$author,$au" = ",$me" || {
mailScript="$mailScript"'
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-16 22:09 UTC (permalink / raw)
To: martin.langhoff; +Cc: git
Martin Langhoff wrote:
>>From what I understand, you'll want the StGIT infrastructure. If you
>use git/cogito, there is an underlying assumption that you'll want
>all the patches merged across, and a simple cg-update will bring in
>all the pending stuff.
>
My concerns are both metodologicals and practical:
1) Method: To use the 'free patching workflow' on git is something foreseen in
git design, something coherent with the fork + develop + merge cycle that it
seems, at least to me, THE way git is meant to be used. Or it is stretching
the possibility of the tool to something technically allowed but not suggested.
2) Practical: The round trip git-format-patch + git-applymbox is the logical and
natural way to reach this goal or, also in this case, I intend to stretch some tools,
designed for one thing, for something else?
About StGIT, I agree it is the right tool, designed for this kind of problems. But,
peraphs because I don't know it very much, I still can't figure out how to integrate
StGit in a git GUI, like qgit is, so to have an unified and friendly view of a git
archive and a patches stack.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Linus Torvalds @ 2005-08-16 21:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek8t8sgi.fsf@assigned-by-dhcp.cox.net>
On Tue, 16 Aug 2005, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > We've got a "git prune-packed", it would be good to have a "git
> > prune-alternate" or something equivalent.
>
> If you have GIT_ALTERNATE_DIRECTORIES environment variable, git
> prune-packed will remove objects from your repository if it is
> found in somebody else's pack. I am not sure if this is the
> behaviour we would want.
Well, it may be good enough if the "master" repository is regularly
packed..
Linus
^ permalink raw reply
* Re: [PATCH] Alternate object pool mechanism updates.
From: Junio C Hamano @ 2005-08-16 21:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508141726390.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> We've got a "git prune-packed", it would be good to have a "git
> prune-alternate" or something equivalent.
If you have GIT_ALTERNATE_DIRECTORIES environment variable, git
prune-packed will remove objects from your repository if it is
found in somebody else's pack. I am not sure if this is the
behaviour we would want.
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-16 21:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
>
>I would like to know a bit about "git format-patch" adding extra
>info that you needed to get rid of. It shouldn't be necessary.
>
As example, in the rev d5a63b99835017d2638e55a7e34a35a3c1e80f1f from git
the original subject is:
' Alternate object pool mechanism updates.'
while, after the round-trip git-format-patch + git applymbox I have
' [PATCH] Alternate object pool mechanism updates.'
The extra '[PATCH]' in the subject was introduced by git-format-patch --mbox.
Perpahs I have made something wrong.
Marco
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] Add merge detection to git-cvsimport
From: Martin Langhoff @ 2005-08-16 21:36 UTC (permalink / raw)
To: skimo, Martin Langhoff, git
In-Reply-To: <20050816110725.GL11882MdfPADPa@garage.linux.student.kuleuven.ac.be>
On 8/16/05, Sven Verdoolaege <skimo@kotnet.org> wrote:
> On Tue, Aug 16, 2005 at 10:35:27PM +1200, Martin Langhoff wrote:
> > +
> > +sub get_headref($$) {
>
> If you want to check whether a ref is valid, then
> it is better to use git-rev-parse...
We are reading/writing directly to .git/refs/heads/ a lot in this
script. Not changing that for the time being.
> > + if (open(C,"$git_dir/refs/heads/$name")) {
> > + chomp($sha = <C>);
> > + close(C);
> > + length($sha) == 40
> > + or die "Cannot get head id for $name ($sha): $!\n";
>
> ... but if you're just going to die, then why not simply
> let git-commit-tree do the test ?
Because we get the head names from cvsps output, and we want to have a
specific error when cvsps has given us a bogus branch name.
git-commit-tree could fail for a number of reasons, this one is the
most likely one to be from a bug in cvsps or the cvsimport logic.
> > + if ($mparent eq 'HEAD') { $mparent = 'origin'};
>
> Please don't hardcode 'origin' here.
Duh! Patch submitted. Juniooooo!
martin
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Martin Langhoff @ 2005-08-16 21:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com>
On 8/17/05, Marco Costalba <mcostalba@yahoo.it> wrote:
> What do you think?
>From what I understand, you'll want the StGIT infrastructure. If you
use git/cogito, there is an underlying assumption that you'll want
all the patches merged across, and a simple cg-update will bring in
all the pending stuff.
cheers,
martin
^ permalink raw reply
* [PATCH] git-cvsimport - remove hardcoded reference to origin
From: Martin Langhoff @ 2005-08-16 21:27 UTC (permalink / raw)
To: git
[PATCH] git-cvsimport - remove hardcoded reference to origin
Signed-off-by: Martin Langhoff <martin.langhoff@gmail.com>
---
git-cvsimport-script | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
61d32d57375d751f565baf61a144ebd6e0d6a61d
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -578,7 +578,7 @@ my $commit = sub {
foreach my $rx (@mergerx) {
if ($logmsg =~ $rx) {
my $mparent = $1;
- if ($mparent eq 'HEAD') { $mparent = 'origin'};
+ if ($mparent eq 'HEAD') { $mparent = $opt_o };
if ( -e "$git_dir/refs/heads/$mparent") {
$mparent = get_headref($mparent, $git_dir);
push @par, '-p', $mparent;
^ permalink raw reply
* [PATCH] cg-admin-cat ignoring -r
From: Pavel Roskin @ 2005-08-16 21:22 UTC (permalink / raw)
To: Petr Baudis, git
Hello!
cg-admin-cat ignores the argument for the "-r" option because it uses
optparse incorrectly. For OPTARG to be set, "-r=" should be used
instead of "-r".
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/cg-admin-cat b/cg-admin-cat
--- a/cg-admin-cat
+++ b/cg-admin-cat
@@ -27,7 +27,7 @@ USAGE="cg-admin-cat [-r TREE_ID] FILE...
rev=HEAD
while optparse; do
- if optparse -r; then
+ if optparse -r=; then
rev="$OPTARG"
else
optfail
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Junio C Hamano @ 2005-08-16 21:09 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050816171142.GB20016@hpsvcnb.fc.hp.com>
Carl Baldwin <cnb@fc.hp.com> writes:
> If I may, let me give an example of something I think could serve the
> purpose a little more simply and generically.
>
> Let's say I start with the following:
> % ls .git/refs/heads
> master
> mylocalbranch
> myremotebranch
> ko-master
> % cat .git/branches/ko-master
> master.kernel.org:/pub/scm/git/git.git
>
> I would add something like this: (I didn't put much thought into the
> actual directory and file names, forgive me. ;-)
>
> % cat .git/branches/relationships
> pull:ko-master:master
> pull:master:mylocalbranch # The next two document my flow locally
> pull:mylocalbranch:master
> push:master:myremotebranch # I push my master to a remote that I control
And presumably you have .git/branches/myremotebranch file that
says something like "master.kernel.org:/pub/scm/git/git.git".
Or should the last line of relationships file be spelled just
push:master:ko-master?
> % cat .git/remotes/ko
> push: master:ko-master pu:ko-pu rc:ko-rc
> pull: ko-master:master ko-pu:pu ko-rc:rc
>
> I might argue that this is now a job for a porcelain script or
> something.
Probably.
My primary interest in discussing this is to see Porcelain folks
agree on what notation and semantics to use, and probably set an
example by having the minimum base in the barebone Porcelain.
Personally I think there are two kinds of patch-flow: one that
is pretty much static that can easily be described with
something like your relationships notation, and ad-hoc one that
I think should not automatically contaminate the established
static flow your relationships notation nicely describes. The
corporate world may put disproportional stress on the importance
of the former, but my feeling is that ad-hoc patch-flow that is
outside your usual static patch-flow is just as important; see
Documentation/howto/using-topic-branches.txt for why.
^ permalink raw reply
* Re: [PATCH] Change git-branch to list branches
From: Junio C Hamano @ 2005-08-16 21:08 UTC (permalink / raw)
To: Kalle Valo; +Cc: Amos Waterland, junkio, git
In-Reply-To: <87d5odlq6l.fsf_-_@litku.valo.iki.fi>
Kalle Valo <Kalle.Valo@iki.fi> writes:
> If no argument provided to `git branch`, show available branches and
> mark current branch with star.
I like the general direction, but this particular implementation
may be a bit troublesome.
> +if [ -z "$branchname" ]; then
> + current=$(basename $(readlink $GIT_DIR/HEAD))
> + cd $GIT_DIR/refs/heads &&
> + ls | sed -e "s/^/ /" -e "s/ $current/* $current/"
> + exit
> +fi
I do not think we have agreed to limit ourselves to a flat
namespace under refs/heads without subdirectories. Something
like what git-show-branches-script does when $# == 0, perhaps?
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Junio C Hamano @ 2005-08-16 21:02 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050816200132.88287.qmail@web26304.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> It is just a very thin layer above the two git scripts, the only extra work
> is the cleaning up of some info that git-format-patch-script automatically adds,
> so that the new commits look like the originals (i.e. same header and description).
> What do you think?
All good. The existing tools are designed to work well in the
following workflow:
$ git format-patch --mbox master..pu
$ cat 000[234]-*.txt >to-apply
$ git checkout master
$ git applymbox to-apply
$ mv .git/refs/heads/pu .git/refs/heads/old-pu
$ git checkout -b pu master
$ git applymbox 0001-*.txt
to advance "master" with selected commits, possibly reordered,
from the "pu" branch, and rebase the "pu" branch using the
remaining commits.
I would like to know a bit about "git format-patch" adding extra
info that you needed to get rid of. It shouldn't be necessary.
^ permalink raw reply
* Re: Making note, in the repository, of push/pull relationships
From: Johannes Schindelin @ 2005-08-16 20:45 UTC (permalink / raw)
To: Carl Baldwin; +Cc: git
In-Reply-To: <20050816160327.GA20016@hpsvcnb.fc.hp.com>
Hi,
On Tue, 16 Aug 2005, Carl Baldwin wrote:
> So, just a question. What, exactly, is meant by 'cross-pulling'?
When I say "cross-pulling" I mean that a branch is pulled from a remote
repository, where the named head is called "a", but that reference is
pulled into the local branch whose head is "b".
Example:
--snip--
> git-ls-remote-script junio
abe0582207c72ec848e78707577c61a98f5c633d refs/heads/master
c506e5687b9257c6182950f245d58cf839abfae4 refs/heads/pu
1f40c7c24d999675df818f9d7824937a964f9f40 refs/heads/rc
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
b3e9704ecdf48869f635f0aa99ddfb513f885aff refs/tags/v0.99.4
> git-pull-script junio pu:temporary-proposed-updates
[...]
> echo .git/refs/heads/temporary-proposed-updates
c506e5687b9257c6182950f245d58cf839abfae4
--snap--
So, the remote branch "pu" gets cross-pulled to the local branch
"temporary-proposed-updates", i.e. to a local branch of a different name.
Ciao,
Dscho
^ 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