* Re: [PATCH] rev-list: add "--full-objects" flag.
From: Linus Torvalds @ 2005-07-12 4:48 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m1wtnw66cc.fsf@ebiederm.dsl.xmission.com>
On Mon, 11 Jul 2005, Eric W. Biederman wrote:
>
> Looking closer it appears that commit_list_insert is recursive
> and that is what I missed.
Actually, it's "pop_most_recent_commit()" that ends up being the
"recursive" part: it will pop the top-most entry, but as it is popping it
it will push the parents of that entry onto the same list.
So basically, you can get a list of all history by first inserting the top
entry, and then doing "pop_most_recent_commit()" until the list is empty.
Now, git-rev-list ends up being slightly more complex than that, since it
has support for multiple starting points, and marking commits (and thus
their parents) uninteresting, and two other sorting methods in addition to
the default "by date" thing.
And then there's all the issues about tags, trees and blobs, and their
visibility as a function of the commits that are visible and the command
line arguments..
In fact, it turns out that git-rev-list is really the real heart of "git".
Almost everything else revolves around it. Once you grok git-rev-list, you
probably really grok git.
Linus
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Linus Torvalds @ 2005-07-12 4:59 UTC (permalink / raw)
To: Marc Singer; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20050712044352.GA9919@buici.com>
On Mon, 11 Jul 2005, Marc Singer wrote:
>
> Does it make sense to think about this branch as an flow of commits?
> Or is it just a starting point for a line of development?
It's really a flow of commits. Nothing will ever really remember what the
starting point was at some later date if you have done commits, and the
branch will always follow the _head_ of development on that branch.
So if you need to remember the starting point as a _static_ entity, you
need to create a tag pointing to that place. You can do that at any point,
very much including after you've already done development (but before you
forget what to tag ;)
> If I make a branch, check it out, commit changes to it, and then clobber
> the working directory, can I later resume that branch of development
> without creating a new branch?
Absolutely. You can create a branch, commit to it, switch to another
branch, commit to that one, switch back to the branch you created, and
just go on. A branch will always follow the development.
> Do I need to set a tag to mark the last commit on that branch?
No, but as mentioned, _if_ you care about remembering where you _started_
the branch, you may want to tag that.
Of course, most of the time you really really don't care. It will be
largely obvious from the global commit history, which you can trivially
visualize with "gitk --all". You'll see where your branch "split off" the
main branch, and the only case where that is ambiguous is if you started
your branch at the tip of another branch, and no other development has
gone on in that other branch - then you don't see a "fork".
Of course, the other reason you usually don't care where you started is
that you simply don't care. When you use CVS, you usually need to know
where the branch was started (and each point it was merged at) just so
that you can sanely merge it by doing diffs etc. With git, since we have
all the proper history, that's not necessary at all.
So I _suspect_ that most of the time when you create a branch, you don't
need to tag where you started. Others will see what is your development
simply by virtue of it being in your tree and not in other peoples tree,
whether you created a branch for that or not ;)
Linus
^ permalink raw reply
* How to get a directory filled with v2.6.11?
From: Marc Singer @ 2005-07-12 5:03 UTC (permalink / raw)
To: git
I switched to using the git version in source control.
Checkout/branching works great. :-)
But, this version of git doesn't let me do
# git checkout -f v2.6.11
error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit
Needed a single revision
which I suspect is protection added to prevent my special sort of
shenanigans. If I cannot perform the checkout anymore, is there
another way to fill a directory with the contents of that particular
tree?
What am I doing? I've got some updates against 2.6.11 orphaned in
another develpment directory. I could just upack a tar.bz2 file for
2.6.11, but git is more clever. I want to perform a diff against the
tagged v2.6.11 and my development tree.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Marc Singer @ 2005-07-12 5:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507112149290.17536@g5.osdl.org>
On Mon, Jul 11, 2005 at 09:59:25PM -0700, Linus Torvalds wrote:
>
>
> On Mon, 11 Jul 2005, Marc Singer wrote:
> >
> > Does it make sense to think about this branch as an flow of commits?
> > Or is it just a starting point for a line of development?
>
> It's really a flow of commits. Nothing will ever really remember what the
> starting point was at some later date if you have done commits, and the
> branch will always follow the _head_ of development on that branch.
That's the important detail.
As an aside, we (a vary large set of developers) have been using SCM
tools for how-many-freakin-years and only now am I seeing something
sane. Cheers.
^ permalink raw reply
* Why is there no git-update-cache --modified (aka I give up)
From: Marc Singer @ 2005-07-12 5:52 UTC (permalink / raw)
To: git
# git-diff-cache HEAD
is really nice. But, do I really have to invoke git-update-cache with
every modified file? I could write a script to cul the filenames from
git-diff-cache, but I'm having a hard time believing that that is how
others are preparing their commits.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito 0.12.1
From: Chris Wright @ 2005-07-12 6:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050712010058.GE5981@pasky.ji.cz>
* Petr Baudis (pasky@ucw.cz) wrote:
> here is Cogito 0.12.1, another desperate attempt to keep pace with
> '@' or Linus, the named Human Master Coder. (Linus, the Human Master
> Coder, mumbles arcane do { formulae } while (0)! Some kind of force
> seems to attack your mind. Everything suddenly looks so different...
> You are confused.) Visit the greater spellbook vault at
>
> http://www.kernel.org/pub/software/scm/cogito
The SRPM and RPMS are uploaded to:
http://www.kernel.org/pub/software/scm/cogito/RPMS
thanks,
-chris
^ permalink raw reply
* Re: How to get a directory filled with v2.6.11?
From: Matthias Urlichs @ 2005-07-12 6:18 UTC (permalink / raw)
To: git
In-Reply-To: <20050712050347.GA10751@buici.com>
Hi, Marc Singer wrote:
> v2.6.11, 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c
You can create your own parent-less commit for that tree.
(It's what I did...)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"It was the most earnest ambition I ever had....Not that I ever
really wanted to be a preacher, but because it never occurred to
me that a preacher could be damned. It looked like a safe job."
[Mark Twain, a Biography]
^ permalink raw reply
* Re: [PATCH] tagger id
From: Eric W. Biederman @ 2005-07-12 6:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <m1slyk63k2.fsf_-_@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> This patch adds a command git-id for use on
> the command line to see what git will set your id too,
> and for use in scripts (git-tag-script) so they can get your git id.
>
> The common code for computing the git-id is moved to ident.c
>
> Fix parse_date to not mind being passed a constant date
> to parse.
>
> The code to compute the identifier has been restructured
> to at least make a reasonable stab at error handling. The
> original version had so many unchecked return values it was
> just scary to think about.
Well except for a small bug, but serious bug...
> diff --git a/commit-tree.c b/commit-tree.c
> --- a/commit-tree.c
> +++ b/commit-tree.c
> @@ -184,8 +126,8 @@ int main(int argc, char **argv)
> add_buffer(&buffer, &size, "parent %s\n",
> sha1_to_hex(parent_sha1[i]));
>
> /* Person/date information */
> - add_buffer(&buffer, &size, "author %s <%s> %s\n", gecos, email, date);
> - add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", commitgecos,
> commitemail, realdate);
> + add_buffer(&buffer, &size, "author %s <%s> %s\n", author);
> + add_buffer(&buffer, &size, "committer %s <%s> %s\n\n", committer);
This should be:
> + add_buffer(&buffer, &size, "author %s\n", author);
> + add_buffer(&buffer, &size, "committer %s\n\n", committer);
>
> /* And add the comment */
> while (fgets(comment, sizeof(comment), stdin) != NULL)
> diff --git a/id.c b/id.c
> new file mode 100644
> --- /dev/null
> +++ b/id.c
> @@ -0,0 +1,36 @@
> +#include "cache.h"
> +#include <stdio.h>
> +#include <errno.h>
> +#include <string.h>
> +
> +static char *id_usage = "git-id [--author | --committer]";
> +
> +int main(int argc, char **argv)
> +{
> + char buf[1000];
> + int (*ident)(char *buf, size_t bufsize);
> + int i;
> +
> + ident = git_committer_ident;
Should this default to git_author_ident or git_committer_ident?
I'm not really certain how we expect to use the different flavors.
Eric
^ permalink raw reply
* Re: Why is there no git-update-cache --modified (aka I give up)
From: Petr Baudis @ 2005-07-12 7:26 UTC (permalink / raw)
To: Marc Singer; +Cc: git
In-Reply-To: <20050712055218.GA18192@buici.com>
Dear diary, on Tue, Jul 12, 2005 at 07:52:18AM CEST, I got a letter
where Marc Singer <elf@buici.com> told me that...
> # git-diff-cache HEAD
>
> is really nice. But, do I really have to invoke git-update-cache with
> every modified file? I could write a script to cul the filenames from
> git-diff-cache, but I'm having a hard time believing that that is how
> others are preparing their commits.
It is. :-) It's only that they have cool scripts to do it, e.g.
cg-commit. (You have to enumerate the files explicitly for
git-commit-script as well, IIRC.)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: [PATCH] remove Obsoletes from cogito.spec.in
From: Petr Baudis @ 2005-07-12 7:30 UTC (permalink / raw)
To: Chris Wright; +Cc: git
In-Reply-To: <20050712003345.GO19052@shell0.pdx.osdl.net>
Dear diary, on Tue, Jul 12, 2005 at 02:33:45AM CEST, I got a letter
where Chris Wright <chrisw@osdl.org> told me that...
> This is leftover from early naming, and is no longer relevant.
>
> Signed-off-by: Chris Wright <chrisw@osdl.org>
Thanks, applied. BTW, Josh Boyer of Fedora suggested having the
Provides: git
line in cogito.spec.in as long as it comes with git bundled (which will
be so until git stabilizes, doesn't break backwards compatibility once
in a while, and gets into some regular and reasonably frequent release
cycle). What do you think?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* [PATCH] document CVS vs. git tags
From: Matthias Urlichs @ 2005-07-12 7:29 UTC (permalink / raw)
To: torvalds, git
CVS uses tags for lots of things.
Git doesn't.
Document that, so people may understand.
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -230,3 +230,33 @@ that contain this changed "if" statement
[ Side note. This option is called "--pickaxe-all" because -S
option is internally called "pickaxe", a tool for software
archaeologists.]
+
+
+
+Tagging, Branching and Merging
+------------------------------
+
+In CVS, you need tags for three different (and conflicting) use cases:
+
+* Mark the state of you repository at a given point in time.
+
+ "This is version 0.2."
+
+* Name a branch, i.e. semi-separate line of development.
+
+ "I'm now working on what's going to be version 0.3."
+
+* Remember where you last merged from so that you won't mess up your
+ changes later.
+
+ "Did we integrate that important bugfix from 0.2.1 into 0.3 yet?"
+
+
+Git has different features for each of these uses.
+
+* You mark the current (actually, last-checked-in) state with "git tag".
+
+* You start a new branch with "git checkout -b <name>".
+
+* Git keeps track of what-got-merged-to-where internally.
+
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Petr Baudis @ 2005-07-12 7:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marc Singer, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0507112132170.17536@g5.osdl.org>
Dear diary, on Tue, Jul 12, 2005 at 06:34:33AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
> On Mon, 11 Jul 2005, Linus Torvalds wrote:
> >
> > Of course, if you want to create a new branch "my-branch" and _not_
> > check it out, you could have done so with just
> >
> > git-rev-parse v2.6.12^0 > .git/refs/heads/my-branch
> >
> > which I think I will codify as "git branch".
>
> And now we have that "git branch". It's a trivial one-liner, except with
> the setup and error checking it's actually more like six lines.
Could we please have the branch name written to .git/head-name in case
we switch the branch? The reason is that .git/HEAD may not be always a
symlink. Specifically, I do this - there's a command cg-seek, which will
seek your working tree to a given commit, while staying on the branch
(committing and some other operations are blocked). In that case, I
remove .git/HEAD and replace it with ID of the commit I'm seeked at, and
when I'm "unseeking" back to the top, I replace it with the symlink
again. With some heuristics, I could create .git/head-name at the time
of seek and hope, but I think it'd be cleaner to just always set it
(except when we are on the master branch), if you agree.
Note that even though Cogito won't let you create/change a local branch
yet, it will understand .git/head-name and hopefully behave properly
(although it's totally untested, of course).
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Why is there no git-update-cache --modified (aka I give up)
From: Junio C Hamano @ 2005-07-12 8:14 UTC (permalink / raw)
To: git; +Cc: Marc Singer
In-Reply-To: <20050712055218.GA18192@buici.com>
Marc Singer <elf@buici.com> writes:
> # git-diff-cache HEAD
>
> is really nice. But, do I really have to invoke git-update-cache with
> every modified file? I could write a script to cul the filenames from
> git-diff-cache, but I'm having a hard time believing that that is how
> others are preparing their commits.
Me too. By the way, I think you mean diff-files not
diff-cache.
I'd like to know how others do it, since this was the
first thing I automated when I started using GIT. Having clear
distinction between cache (aka index file) and work tree files
and making user concious decision of when to and when not to
register/update index is what is quite different in GIT from
CVS, SVN and friends [*1*], and while I appreciate its
flexibility, it often ends up to be simply more typing (and to
certain degree more thinking which is not a bad thing) to the
user [*2*].
This snippet is essentially what I do to match the cache with
the current work tree [*3*]:
case "$(git-ls-files --unmerged | sed -e 1q)" in
?*)
echo >&2 You have unmerged files and cannot commit.
exit 1
;;
esac
git-update-cache --refresh >/dev/null
git-diff-files |
sed -e 's/.* //' |
xargs -r git-update-cache --add --remove --
[Footnote]
*1* I vaguely recall reading somewhere that GIT is not the first
SCM to have these three (not two) levels. Usual two-level SCM
needs to only move between your hackery and what's in the repo,
and words like "committing" and "checking in" are used
interchangeably, while the other three level SCM (I do not
remember which one I read about) gives distinct meaning to these
two words. Can anybody tell me which SCM I am talking about?
*2* The commit flow in GIT is three level thing. You have HEAD
version (a commit with an associated tree already in the object
database that you have checked out and started with), you have
cache, and you have files in your work tree. Checking out is to
match cache and work tree to HEAD; update-cache is to match
cache to work tree; and committing is to create a new commit
that matches the cache and make it your HEAD. Roughly speaking,
diff-* brothers are about comparing these three stages:
- diff-files compares cache and work tree
- diff-cache compares commit and cache, or commit and work tree
- diff-tree compares two commits
*3* I do not officially do Porcelain ;-), but the script I use
is slightly different from the one quoted above. It uses
"git-diff-files -z" and a helper program to handle filenames
with TAB in them.
^ permalink raw reply
* Re: [PATCH] tagger id
From: Junio C Hamano @ 2005-07-12 8:44 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m18y0c1prv.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> Should this default to git_author_ident or git_committer_ident?
> I'm not really certain how we expect to use the different flavors.
The only in-tree user after your patch is applied is the tagger
stuff, so in that sense committer_ident may make more sense.
Having said that, for something like this that would not be used
constantly and interatively by the users, my preference is not
to have any default at all, and always require --author or
--committer. You have to type a bit more when doing the script,
but that needs to be done only once. You will be sure which one
you are asking from the command two weeks after you wrote the
script so it is not a big loss.
I am not seriously suggesting the below as an alternative, but
have you thought about doing an inverse function of your
computation for the case when the user has all the environment
variables, and have script eval its output, like this [*1*]:
$ git-id
GIT_AUTHOR_NAME='Junio C Hamano'
GIT_AUTHOR_EMAIL='junkio@cox.net'
GIT_COMMITTER_NAME='Junio C Hamano'
GIT_COMMITTER_EMAIL='junkio@cox.net'
$ eval "`git-id`"
$ tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"
Having names and emails available separately may turn out to be
easier to use in other situation. Just a thought.
By the way, I do not particularly like the name "git-id". There
could be IDs for different kinds (not just people) we would want
later (file IDs, for example). Naming what you are computing
_the_ "id" feels a bit too generic. I do not have a better
alternative to suggest, though.
[Footnote]
*1* This makes its output syntax a bit too specific to the shell
and unfriendly to Porcelain written in other languages. The
only non-shell Porcelains I am aware of are done in Perl (I do
not remember hearing its name) and Python (StGIT), both of which
have reasonable regexp support to grok something like this, so
it would not be a big issue.
^ permalink raw reply
* Re: [PATCH 3/6] git-gnu-progs-Makefile: git Makefile update
From: Matthias Urlichs @ 2005-07-12 9:03 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.58.0507111252380.17536@g5.osdl.org>
Hi, Linus Torvalds wrote:
> I also don't see why, if OS-X already _does_ include the GNU tools, they
> couldn't be under /opt/fsf/bin or something like that, and then you could
> just do
>
> PATH=/opt/fsf/bin:$PATH
We could prepend /usr/lib/git to $PATH, and symlink them with their "real"
names there.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Go directly to jail. Do not pass Go, do not collect $200.
^ permalink raw reply
* Re: Bootstrapping into git, commit gripes at me
From: Junio C Hamano @ 2005-07-12 9:07 UTC (permalink / raw)
To: Petr Baudis; +Cc: Linus Torvalds, Marc Singer, Git Mailing List
In-Reply-To: <20050712074801.GD6363@pasky.ji.cz>
I do want to see various Porcelains to agree on how to store
state information in $GIT_DIR for doing common operations, when
they are conceptually compatible. The way they handle branches
may fall into that category. With the barebone GIT Porcelain,
"seek" like operation may simply be done by creating another
branch or tag and jumping to it, so there may not be the concept
of "seek", in which case they may not be compatible after all.
Having said that, I do like the concept of keeping track of
"which development line are we on, and what's most recent in
it". The way I read your description of cg-seek, you currently
have that information is either in .git/head-name and
.git/refs/heads/<head-name> pair (when .git/head-name exists),
or .git/HEAD.
If you block certain operations while you have seeked to non-top
anyway, wouldn't it be cleaner to have .git/seeked-to that
records the commit ID you are at, which at the same time
indicates that you are in a special situation, and not touching
HEAD at all? Then .git/HEAD will always have that line of
development information.
Well, that was half tongue-in-cheek suggestion; I have a feeling
that you may feel it is a bit too late to change this kind of
thing easily.
But if we are going to agree on using .git/head-name, I'd rather
see it exist all times, so that cat "$GIT_DIR/head-name" would
always tell us which branch we are working in.
^ permalink raw reply
* Re: Stacked GIT 0.4
From: Bryan Larsen @ 2005-07-12 11:05 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT
In-Reply-To: <1120899939.7125.4.camel@localhost.localdomain>
Catalin Marinas wrote:
> Stacked GIT 0.4 release is available from http://procode.org/stgit/
>
Very nice.
Here's my wishlist. Hopefully I'll be able to dig in and help out.
import: the complement to export
template files for the "series" output of export, to put it into a
format that "sendpatchset" understands.
Bryan
^ permalink raw reply
* [PATCH] cg-commit chokes when given a very large list of files
From: Bryan Larsen @ 2005-07-12 11:20 UTC (permalink / raw)
To: bryan.larsen; +Cc: Bryan Larsen, pasky, git
cg-commit currently chokes when passed a very large list of files. Fix it.
This patch depends on your filenames not containing line feeds. No big deal, lots of other parts of cogito break on filenames containing line feeds.
Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---
cg-commit | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/cg-commit b/cg-commit
--- a/cg-commit
+++ b/cg-commit
@@ -288,10 +288,12 @@ precommit_update () {
[ "$op" = "N" ] || [ "$op" = "D" ] || [ "$op" = "M" ] || op=M
eval "queue$op[\${#queue$op[@]}]=\"\$fname\""
done
+ IFS=$'\n'
# XXX: Do we even need to do the --add and --remove update-caches?
- [ "$queueN" ] && { git-update-cache --add ${infoonly} -- "${queueN[@]}" || return 1; }
- [ "$queueD" ] && { git-update-cache --force-remove -- "${queueD[@]}" || return 1; }
- [ "$queueM" ] && { git-update-cache ${infoonly} -- "${queueM[@]}" || return 1; }
+ [ "$queueN" ] && { ( echo "${queueN[*]}" | tr \\n \\0 | xargs -0 git-update-cache --add ${infoonly} -- ) || return 1; }
+ [ "$queueD" ] && { ( echo "${queueD[*]}" | tr \\n \\0 | xargs -0 git-update-cache --force-remove -- ) || return 1; }
+ [ "$queueM" ] && { ( echo "${queueM[*]}" | tr \\n \\0 | xargs -0 git-update-cache ${infoonly} -- ) || return 1; }
+ IFS=$' \n\t'
return 0
}
^ permalink raw reply
* Re: Stacked GIT 0.4
From: Catalin Marinas @ 2005-07-12 13:14 UTC (permalink / raw)
To: Bryan Larsen; +Cc: GIT
In-Reply-To: <42D3A415.5000709@gmail.com>
Bryan Larsen <bryan.larsen@gmail.com> wrote:
> import: the complement to export
It is written in the TODO file but didn't have time to do it. I'm
working on moving all the commands from main.py into separate files
under stgit/commands/ for a clearer view. This should be ready in the
next day or two and, after that, I will work on other commands.
> template files for the "series" output of export, to put it into a
> format that "sendpatchset" understands.
I thought about integrating sendpatchset into stgit but it is much
simpler to just generate a control file (especially if you want to
review what you're going to send). Is the subject line always the
first line of the patch description?
--
Catalin
^ permalink raw reply
* Re: Stacked GIT 0.4
From: Bryan Larsen @ 2005-07-12 13:29 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT
In-Reply-To: <tnxfyukjhdn.fsf@arm.com>
Catalin Marinas wrote:
> Bryan Larsen <bryan.larsen@gmail.com> wrote:
>>template files for the "series" output of export, to put it into a
>>format that "sendpatchset" understands.
>
>
> I thought about integrating sendpatchset into stgit but it is much
> simpler to just generate a control file (especially if you want to
> review what you're going to send). Is the subject line always the
> first line of the patch description?
>
I haven't been using "the Linux way" for long, so I'm probably the wrong
guy to answer, but for my current set of patches, the name of the patch
would be the right thing to put in the Subject line.
But my current set of patches is really small, so if you implemented the
"first line" convention, I'd be happy to switch to it.
Bryan
^ permalink raw reply
* Re: [PATCH 2/2] Demo support for packs via HTTP
From: Darrin Thompson @ 2005-07-12 13:35 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git, Linus Torvalds, Petr Baudis
In-Reply-To: <Pine.LNX.4.21.0507112147400.30848-100000@iabervon.org>
Daniel Barkalow wrote:
> If I understand the curl documentation, you should be able to set options
> on the curl object when it has just been created, if those options aren't
> going to change between requests. Note that I make requests from multiple
> places, but I use the same curl object for all of them.
>
I didn't realize that it was the same object. Great!
--
Darrin
^ permalink raw reply
* Re: [PATCH] tagger id
From: Eric W. Biederman @ 2005-07-12 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7veka48lcw.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> Should this default to git_author_ident or git_committer_ident?
>> I'm not really certain how we expect to use the different flavors.
>
> The only in-tree user after your patch is applied is the tagger
> stuff, so in that sense committer_ident may make more sense.
There is also the commit path, and that comes from C. I'm not
quite certain how we should be using the environmental variables.
> Having said that, for something like this that would not be used
> constantly and interatively by the users, my preference is not
> to have any default at all, and always require --author or
> --committer. You have to type a bit more when doing the script,
> but that needs to be done only once. You will be sure which one
> you are asking from the command two weeks after you wrote the
> script so it is not a big loss.
Make sense. Although I'm not quite certain we actually need the
information twice. Possibly we just have GIT_AUTHOR_NAME and
GIT_AUTHOR_EMAIL, and then have commit-write take a flag to
override the author bit. That would certainly make it less
confusing when setting up environmental variables for git.
And that would also give us a better name.
> I am not seriously suggesting the below as an alternative, but
> have you thought about doing an inverse function of your
> computation for the case when the user has all the environment
> variables, and have script eval its output, like this [*1*]:
>
> $ git-id
> GIT_AUTHOR_NAME='Junio C Hamano'
> GIT_AUTHOR_EMAIL='junkio@cox.net'
> GIT_COMMITTER_NAME='Junio C Hamano'
> GIT_COMMITTER_EMAIL='junkio@cox.net'
> $ eval "`git-id`"
> $ tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL>"
>
> Having names and emails available separately may turn out to be
> easier to use in other situation. Just a thought.
Part of the request was to put all of this information together
in a common place. And note that it is actually:
tagger="$GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> $GIT_COMMITTER_DATE"
Where the date is a human unreadable string of the number of seconds
since the epoch (aka 1 Jan 1970 UTC).
> By the way, I do not particularly like the name "git-id". There
> could be IDs for different kinds (not just people) we would want
> later (file IDs, for example). Naming what you are computing
> _the_ "id" feels a bit too generic. I do not have a better
> alternative to suggest, though.
Agreed. Something like git-author or git-author-stamp is probably
better.
> *1* This makes its output syntax a bit too specific to the shell
> and unfriendly to Porcelain written in other languages. The
> only non-shell Porcelains I am aware of are done in Perl (I do
> not remember hearing its name) and Python (StGIT), both of which
> have reasonable regexp support to grok something like this, so
> it would not be a big issue.
And in git-commit-script this is actually parsed by sed which makes
it so the shell can parse the information as well so I think
we are fine in that sense.
Eric
^ permalink raw reply
* Re: [PATCH] tagger id
From: Petr Baudis @ 2005-07-12 15:14 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: Junio C Hamano, git
In-Reply-To: <m14qb012x4.fsf@ebiederm.dsl.xmission.com>
Dear diary, on Tue, Jul 12, 2005 at 05:04:23PM CEST, I got a letter
where "Eric W. Biederman" <ebiederm@xmission.com> told me that...
> > By the way, I do not particularly like the name "git-id". There
> > could be IDs for different kinds (not just people) we would want
> > later (file IDs, for example). Naming what you are computing
> > _the_ "id" feels a bit too generic. I do not have a better
> > alternative to suggest, though.
>
> Agreed. Something like git-author or git-author-stamp is probably
> better.
Since that "infriges" the author/committer distinction, I would prefer
git-person-id.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
<Espy> be careful, some twit might quote you out of context..
^ permalink raw reply
* Re: Why is there no git-update-cache --modified (aka I give up)
From: Marc Singer @ 2005-07-12 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jfwbfvj.fsf@assigned-by-dhcp.cox.net>
On Tue, Jul 12, 2005 at 01:14:24AM -0700, Junio C Hamano wrote:
> Marc Singer <elf@buici.com> writes:
>
> > # git-diff-cache HEAD
> >
> > is really nice. But, do I really have to invoke git-update-cache with
> > every modified file? I could write a script to cul the filenames from
> > git-diff-cache, but I'm having a hard time believing that that is how
> > others are preparing their commits.
>
> Me too. By the way, I think you mean diff-files not
> diff-cache.
No, I mean git-diff-cache. I find that this works pretty well, though.
# git-update-cache `git-diff-cache | cut -f2`
It looks like the same thing works for git-diff-files.
# git-update-cache `git-diff-files | cut -f2`
This seems to agree with the way you handle things.
Similarly, there is the need to determine which files are new to the
tree. This isn't much of a burden when creating files in the tree,
but can be bothersome when using patch since git-apply is conservative
about fuzz.
^ permalink raw reply
* Re: Trial git RPM's..
From: Eric W. Biederman @ 2005-07-12 15:59 UTC (permalink / raw)
To: Chris Wright; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <20050711210309.GT5324@shell0.pdx.osdl.net>
Chris Wright <chrisw@osdl.org> writes:
> * Linus Torvalds (torvalds@osdl.org) wrote:
>> > And it does not pass my torture test of building rpm's on debian,
>> > but that is not a huge problem.
>>
>> Ok, why is debian problematic? Is there some missing dependency or
>> something? I really haven't ever done an rpm, and the git rpm target was
>> all done by Chris Wright, so I don't have any clue at all. Again, patches
>> welcome.
>
> Heh debian rpm build...I missed that bit in Eric's message. Eric, care
> to give details?
Ok paged back in my state. The practical problem is that rpmbuild try
to lookup the build dependencies which simply aren't present on debian.
Patch will be along shortly once I get the glitches fixed.
One last issue with building packages. Some distros are still shipping
GNU interactive tools so git as a package name for the rpm is problematic.
At the very least it is extremely confusing that git-0.99 is a more
recent package that git-4.3.20.
Eric
^ 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