* Re: [EGIT PATCH 3/6] Add a method to get refs by object Id
From: Shawn O. Pearce @ 2008-10-06 22:43 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200810070037.53841.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> måndagen den 6 oktober 2008 10.15.54 skrev Shawn O. Pearce:
> > Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > >
> > > /**
> > > + * @return a map with all objects referenced by a peeled ref.
> > > + */
> > > + public Map<AnyObjectId, List<Ref>> getAllRefsByPeeledObjectId() {
> >
> > Do we really want to promise List here? Can we make it just
> > Collection instead?
>
> Sure. Our promise is actually slightly better, it is Set, but Java doesn't have a suitable class for that.
java.util.Set? java.util.HashSet?
What am I missing?
> > > + for (Map.Entry<String,Ref> e : allRefs.entrySet()) {
> > > + Ref ref = e.getValue();
> >
> > I think this is cleaner:
> >
> > for (Ref ref : allRefs.values()) {
> >
> > as you never use the key.
>
> Yes. I was thinking it might be less efficient, but the JDK implementation looks quite well optimized in 1.6 at least
> so values() is slightly faster.
I wasn't concerned about performance, I was going for readability.
This loop is probably not performance critical as its done once
early when the PlotWalk starts. I just found that grabbing the
entrySet when all you care about is the values was odd.
> > List<Ref> nl = Collections.singletonList(ref);
> > List<Ref> ol = ret.put(target, nl);
> > if (ol != null) {
> > if (ol.size() == 1) {
> > nl = new ArrayList<Ref>(2);
> > nl.add(ol.get(0));
> > nl.add(ref);
> > ret.put(target, nl);
> > } else {
> > ol.add(ref)
> > ret.put(target, ol);
> > }
> > }
>
> ok, I guess one just has has to include the comment on why for the casual reader.
I'm probably too used to this pattern of "put, then test" because
I use it a lot when the odds of put returning null are very high.
Its an odd idiom. I think most developers wouldn't write it.
So I guess a comment of some sort is probably a good idea if you
chose to use this mess. ;-)
--
Shawn.
^ permalink raw reply
* Re: [EGIT PATCH 3/6] Add a method to get refs by object Id
From: Robin Rosenberg @ 2008-10-06 22:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006081554.GD27516@spearce.org>
måndagen den 6 oktober 2008 10.15.54 skrev Shawn O. Pearce:
> Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> > diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > index dfce1b8..3fc5236 100644
> > --- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > +++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
> > @@ -939,6 +940,33 @@ public String getBranch() throws IOException {
> > }
> >
> > /**
> > + * @return a map with all objects referenced by a peeled ref.
> > + */
> > + public Map<AnyObjectId, List<Ref>> getAllRefsByPeeledObjectId() {
>
> Do we really want to promise List here? Can we make it just
> Collection instead?
Sure. Our promise is actually slightly better, it is Set, but Java doesn't have a suitable class for that.
>
> > + Map<String, Ref> allRefs = getAllRefs();
> > + HashMap<AnyObjectId, List<Ref>> ret = new HashMap<AnyObjectId, List<Ref>>(allRefs.size());
> > + for (Map.Entry<String,Ref> e : allRefs.entrySet()) {
> > + Ref ref = e.getValue();
>
> I think this is cleaner:
>
> for (Ref ref : allRefs.values()) {
>
> as you never use the key.
Yes. I was thinking it might be less efficient, but the JDK implementation looks quite well optimized in 1.6 at least
so values() is slightly faster.
> > + AnyObjectId target = ref.getPeeledObjectId();
> > + if (target == null)
> > + target = ref.getObjectId();
> > + List<Ref> list = ret.get(target);
> > + if (list == null) {
> > + list = Collections.singletonList(ref);
> > + } else {
> > + if (list.size() == 1) {
> > + ArrayList<Ref> list2 = new ArrayList<Ref>(2);
> > + list2.add(list.get(0));
> > + list = list2;
> > + }
> > + list.add(ref);
> > + }
> > + ret.put(target, list);
>
> Hmm. Putting the list every time is pointless. This is may run
> faster because we (on average) only do one hash lookup per target,
> not 2:
>
> List<Ref> nl = Collections.singletonList(ref);
> List<Ref> ol = ret.put(target, nl);
> if (ol != null) {
> if (ol.size() == 1) {
> nl = new ArrayList<Ref>(2);
> nl.add(ol.get(0));
> nl.add(ref);
> ret.put(target, nl);
> } else {
> ol.add(ref)
> ret.put(target, ol);
> }
> }
ok, I guess one just has has to include the comment on why for the casual reader.
-- robin
^ permalink raw reply
* [PATCH] Implement git clone -v
From: Miklos Vajna @ 2008-10-06 22:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: Constantine Plotnikov, git
In-Reply-To: <81b0412b0810041442i3aa29628lf66ef9b188fe8ce7@mail.gmail.com>
The new -v option forces the progressbar, even in case the output is not
a terminal.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Sat, Oct 04, 2008 at 11:42:15PM +0200, Alex Riesen <raa.lkml@gmail.com> wrote:
> 2008/10/3 Constantine Plotnikov <constantine.plotnikov@gmail.com>:
> > Is there a way to force a progress output on stderr for git clone
> > preferably using options or environment variables?
>
> No, but "-v" option is not used for anything yet, so you are free to
> implement it.
Something like this?
Documentation/git-clone.txt | 5 +++++
builtin-clone.c | 4 ++++
transport.c | 2 +-
transport.h | 2 ++
4 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 0e14e73..95f08b9 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -90,6 +90,11 @@ then the cloned repository will become corrupt.
Operate quietly. This flag is also passed to the `rsync'
command when given.
+--verbose::
+-v::
+ Display the progressbar, even in case the standard output is not
+ a terminal.
+
--no-checkout::
-n::
No checkout of HEAD is performed after the clone is complete.
diff --git a/builtin-clone.c b/builtin-clone.c
index 49d2eb9..df71b23 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -38,9 +38,11 @@ static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
static char *option_upload_pack = "git-upload-pack";
+static int option_verbose;
static struct option builtin_clone_options[] = {
OPT__QUIET(&option_quiet),
+ OPT__VERBOSE(&option_verbose),
OPT_BOOLEAN('n', "no-checkout", &option_no_checkout,
"don't create a checkout"),
OPT_BOOLEAN(0, "bare", &option_bare, "create a bare repository"),
@@ -506,6 +508,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_quiet)
transport->verbose = -1;
+ else if (option_verbose)
+ transport->progress = 1;
if (option_upload_pack)
transport_set_option(transport, TRANS_OPT_UPLOADPACK,
diff --git a/transport.c b/transport.c
index 5110c56..1c510a3 100644
--- a/transport.c
+++ b/transport.c
@@ -644,7 +644,7 @@ static int fetch_refs_via_pack(struct transport *transport,
args.include_tag = data->followtags;
args.verbose = (transport->verbose > 0);
args.quiet = (transport->verbose < 0);
- args.no_progress = args.quiet || !isatty(1);
+ args.no_progress = args.quiet || (!transport->progress && !isatty(1));
args.depth = data->depth;
for (i = 0; i < nr_heads; i++)
diff --git a/transport.h b/transport.h
index d0b5205..6bbc1a8 100644
--- a/transport.h
+++ b/transport.h
@@ -25,6 +25,8 @@ struct transport {
int (*disconnect)(struct transport *connection);
char *pack_lockfile;
signed verbose : 2;
+ /* Force progress even if the output is not a tty */
+ unsigned progress : 1;
};
#define TRANSPORT_PUSH_ALL 1
--
1.6.0.2
^ permalink raw reply related
* RE: gitweb improvements
From: Tjernlund @ 2008-10-06 22:17 UTC (permalink / raw)
To: 'Jakub Narebski'; +Cc: 'git'
In-Reply-To: <200810060154.06934.jnareb@gmail.com>
> -----Original Message-----
> From: Jakub Narebski [mailto:jnareb@gmail.com]
> Sent: den 6 oktober 2008 01:54
> To: Tjernlund
> Cc: 'git'
> Subject: Re: gitweb improvements
>
> On Mon, 6 Oct 2008, Tjernlund wrote:
> > Jakub Narebski wrote:
> >> "Tjernlund" <tjernlund@tjernlund.se> writes:
>
> >>> 2) looking at a merge like:
> >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-
> 2.6.git;a=commit;h=66120005e65eed8a05b14a36ab448bdec42f0d6b
> >>> is somewhat confusing. It really doesn't tell you which commits that is
> >>> included in the merge.
> >>
> >> I don't understand you there. First, you have "(merge: 0d0f3ef 9778e9a)"
> >> in the navbar, so you can easily go to commit view for parents. Second,
> >> among commit headers you have two "parent", where SHA-1 of a commit is
> >> hidden link, and there are also 'commit' and 'diff' link for those.
> >
> > hmm, looks like I overlooked "(merge: 0d0f3ef 9778e9a)" part. However, I can't
> > find the "ALSA: make the CS4270 driver a new-style I2C driver" from within
> > this page.
>
> I think you don't quite understand the situation. The history looks
> like this:
>
> M Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
> |\
> | 2 ALSA: ASoC: Fix another cs4270 error path
> | * ALSA: make the CS4270 driver a new-style I2C driver
> | |
> 1 | Merge git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6
>
> Parents of commit 'M' (for merge) are '1' and '2', not 2,* or 1,2,*.
>
> Now the fact that commit message for merge contains shortlog of merged
> branch does not mean that there must be direct link to such shortlog.
> You can go to shortlog (well, kind of) if you click on second parent,
> _then_ click on shortlog link at top of the page.
You are quite right, I didn't quite follow the situation. I do however have one
observation, would it be possible to list the commits in a merge the same way
you list commits on the top level, that is, more or less make the headings
"ALSA: ASoC: Fix another cs4270 error path"
"ALSA: make the CS4270 driver a new-style I2C driver"
links one can follow?
Jocke
^ permalink raw reply
* Re: [EGIT PATCH 4/6] Add tags to the graphical history display.
From: Shawn O. Pearce @ 2008-10-06 22:14 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200810062358.44954.robin.rosenberg@dewire.com>
Robin Rosenberg <robin.rosenberg@dewire.com> wrote:
> måndagen den 6 oktober 2008 10.08.34 skrev Shawn O. Pearce:
> > Maybe PlotWalk should override next() [...]
>
> I missed something here I think. Thanks. Maybe I thought... doesn't matter.
> I'll rewrite the changes in and related to this completely.
OK, looking forward to the changes.
> > > @@ -54,6 +66,7 @@
> > > public PlotWalk(final Repository repo) {
> > > super(repo);
> > > super.sort(RevSort.TOPO, true);
> > > + reverseRefMap = repo.getAllRefsByPeeledObjectId();
> >
> > I wonder if this shouldn't be done as part of the StartGenerator
> > (or something like it but specialized for PlotWalk). I only say
> > that because a reused PlotWalk may want to make sure its ref map
> > is current with the repository its about to walk against.
>
> noted.
Be careful. StartGenerator is package access only and I think
PlotWalk is in a different package.
IMHO binding into the StartGenerator (by subclassing it and replacing
it) feels like the right thing to me, but it means making a bunch
of changes to RevWalk and StartGenerator to make that type public
and allow PlotWalk to inject a different subclass of StartGenerator
for itself.
The StartGenerator trick is very useful though; it allows the RevWalk
to perform init activity only on the first invocation of next()
and then removes the init code entirely from the call path. It is a
virtual dispatch, but I figured its a virtual dispatch anyway due to
the way the other generators are chained together based the filters
so we at least avoid a "if (first) {...}" test on every call to next.
> > You are inside of a PlotWalk, which extends RevWalk, which has very
> > aggressive caching of RevCommit and RevTag data instances, and very
> > fast parsers. Much faster than the legacy Commit and Tag classes.
>
> Maybe we should rid us of them completely and make new commit from
> these classes of possible more lightweight ones. The old classes were
> straightforward but are on overtime now.
I'm trying to go in that direction. However there are three reasons
why we aren't ready yet:
- Commits can only be made by the old-style Commit class.
- Tags can only be made by the old-style Tag class.
- Trees can only be made by the old-style Tree class.
I have some experimental code in my merge branch to solve the last
one by teaching DirCache how to write out the index and update the
cache trees with the ObjectIds of the newly created trees, but I
have not had a chance to clean the patches up with test cases and
docs to submit to the git ML yet.
So I'm actively working on fixing the last item.
Oh, and of course existing callers have to be converted. But I am
trying to avoid introducing new callers.
> As you noted earlier we usually have at most one ref per commit to sort.
> Not much to optimize for speed here with current repos. For a one-element
> list the compare routine wil not even be invoked.
Oh, good point.
> > In hindsight those RevCommit[] probably should be a List<RevCommit>
> > with different list implementations based on the number of parents
> > needed:
> >
> > 0 parents: Collections.emptyList()
> > 1 parent: Collections.singletonList()
> > 2 parents: some especialized AbstractList subclass
> > 3 parents: ArrayList
>
> I guess measuring is the right way. For these small arrays, my bet
> is that List is way faster because we do not need any bounds checking.
> Hotspot is reasonably good at optimizing those away, but that won't
> help for much small arrays.
Yup. Its something to explore. But I lack the time right now so
I'm going going to be making any changes and measuring it anytime
soon. ;-)
Maybe someone who wants to get involved can look at this. Or any
other number of issues we still have open.
But without measurements to back up the code either way I won't be
making changes to what we have right now.
--
Shawn.
^ permalink raw reply
* files missing after converting a cvs repository to git
From: Adam Mercer @ 2008-10-06 22:02 UTC (permalink / raw)
To: GIT
Hi
One of the prrojects I am involved with is currently looking into
migrating from cvs to git, therefore we have been investigating this
by setting up a git repository that tracks cvs, however there are some
very strange things going on and I was hoping someone could offer some
insight into what is going on.
I use the following git cvsimport command to import the repository:
$ git cvsimport -v -a -i -k
-d:pserver:user@server:port/path/to/cvs/repo -C /path/to/new/git/repo
module
this ran successfully with no warnings or errors. However, when I
checkout the new git repository that are several files missing from
the git checkout that are present in the cvs checkout.
Does anyone know why this would happen, or how to find out? This is a
major problem because we will be unable to migrate to cvs until this
can be solved.
Cheers
Adam
^ permalink raw reply
* Re: [EGIT PATCH 4/6] Add tags to the graphical history display.
From: Robin Rosenberg @ 2008-10-06 21:58 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006080834.GC27516@spearce.org>
måndagen den 6 oktober 2008 10.08.34 skrev Shawn O. Pearce:
> FYI, my comments don't fully cover this patch yet.
>
> > - protected PlotCommit(final AnyObjectId id) {
> > + protected PlotCommit(final AnyObjectId id, final Ref[] tags) {
> > super(id);
> > + this.refs = tags;
>
> this.refs isn't final. There is no reason to be adding it to the
> constructor and having this ripple effect all the way up into the
> RevWalk class.
Eh, it doesn't, ecept I added a methos to RevWalk than can return tags,
which it doesn't unless the information is attached.
> Maybe PlotWalk should override next() and only set PlotCommit.refs on
> things returned from super.next()? This way we only do tag lookup
> on commits that the filtering rules have said should be shown in
> to the application, but the refs should still be inserted prior to
> the application seeing the RevCommit.
I missed something here I think. Thanks. Maybe I thought... doesn't matter.
I'll rewrite the changes in and related to this completely.
> > @@ -54,6 +66,7 @@
> > public PlotWalk(final Repository repo) {
> > super(repo);
> > super.sort(RevSort.TOPO, true);
> > + reverseRefMap = repo.getAllRefsByPeeledObjectId();
>
> I wonder if this shouldn't be done as part of the StartGenerator
> (or something like it but specialized for PlotWalk). I only say
> that because a reused PlotWalk may want to make sure its ref map
> is current with the repository its about to walk against.
noted.
> You are inside of a PlotWalk, which extends RevWalk, which has very
> aggressive caching of RevCommit and RevTag data instances, and very
> fast parsers. Much faster than the legacy Commit and Tag classes.
Maybe we should rid us of them completely and make new commit from
these classes of possible more lightweight ones. The old classes were
straightforward but are on overtime now.
> I think we should use the RevCommit and RevTag classes to handle
> sorting here. RevCommit already has the committer time cached
> and stored in an int. RevCommit probably should learn to do the
> same for its "tagger" field. The tiny extra bloat (1 word) that
> adds to a RevTag instance is worth it when we consider implementing
> something like this and/or git-describe where sorting tags by their
> dates is useful.
As you noted earlier we usually have at most one ref per commit to sort.
Not much to optimize for speed here with current repos. For a one-element
list the compare routine wil not even be invoked.
>
> > + tags = list.toArray(new Ref[list.size()]);
>
> I wonder if using a Ref[] here even makes sense given that the data
> is stored in a List<Ref>. I use RevCommit[] inside of RevCommit
> generally because the number of entries in the array is 1 or 2 and
> the array is smaller than say an ArrayList.
>
> In hindsight those RevCommit[] probably should be a List<RevCommit>
> with different list implementations based on the number of parents
> needed:
>
> 0 parents: Collections.emptyList()
> 1 parent: Collections.singletonList()
> 2 parents: some especialized AbstractList subclass
> 3 parents: ArrayList
>
> I think it would actually use less memory per instance, which is
> a huge bonus, but we'd pay a downcasting penalty on each access.
> HotSpot is supposed to be really good at removing the downcast
> penalty from say java.util.List, but I don't if it can beat a typed
> array access.
I guess measuring is the right way. For these small arrays, my bet
is that List is way faster because we do not need any bounds checking.
Hotspot is reasonably good at optimizing those away, but that won't
help for much small arrays.
> Sorry I got off on a bit of a tangent here. I'm just trying to
> point out that the primary reason I've usd an array before is
> probably moot here since the data is already in a List.
Could it be that arrays are often better then lists.
> > diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > index d7e4c58..41d57c6 100644
> > --- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > +++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevWalk.java
> > @@ -53,6 +53,7 @@
>
> IMHO this class shouldn't need to be modified.
>
> > @@ -541,7 +542,7 @@ public RevTree lookupTree(final AnyObjectId id) {
> > public RevCommit lookupCommit(final AnyObjectId id) {
> > RevCommit c = (RevCommit) objects.get(id);
> > if (c == null) {
> > - c = createCommit(id);
> > + c = createCommit(id, getTags(id));
>
> This code is performance critical to commit parsing. Trying to
> lookup tags for every commit we evaluate, especially ones that we
> will never show in the UI (because they are uninteresting) but that
> we still need to parse in order to derive the merge base is just
> a huge waste of time.
>
> Same applies for the lookupAny and parseAny methods.
>
Ack.
-- robin
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Samuel Tardieu @ 2008-10-06 21:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Karl Hasselström, git
In-Reply-To: <b0943d9e0810061414ja87488k6aef65fec0856144@mail.gmail.com>
>>>>> "Catalin" == Catalin Marinas <catalin.marinas@gmail.com> writes:
Catalin> I wouldn't advertise the refreshing of "any" patch as it
Catalin> doesn't always work (it actually fails in a lot of cases). Or
Catalin> at least we could mention that there are some restrictions.
Does it? I use it all the times.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [StGit PATCH 6/6] Refresh and expand the tutorial (not finished)
From: Catalin Marinas @ 2008-10-06 21:25 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160203.19886.33463.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> This is a first pass at expanding the tutorial, fixing its formatting,
> and updating it with the new things that have happened in StGit.
>
> There are a number of things still left to do in the second half of
> the document; they are tagged with "TODO".
Thanks for this. Even with the TODOs, I think we can merge them into
the master branch so that I have the same copy as you. Do you plan to
do more work on the tutorial (so that we don't duplicate)?
> -Layout of the .git directory
Should we mention the metadata storage somewhere? This is probably too
advanced for the tutorial but might be useful to have it in a
development document (for other to understand where we keep things).
Actually, is the automatically generated documentation from the new
infrastructure enough?
--
Catalin
^ permalink raw reply
* Re: [FYI][PATCH] Customizing the WinGit installer
From: Abdelrazak Younes @ 2008-10-06 21:19 UTC (permalink / raw)
To: Johannes.Schindelin
Cc: Linus Torvalds, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On 06/10/2008 20:01, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 6 Oct 2008, Linus Torvalds wrote:
>
>> On Mon, 6 Oct 2008, Johannes Schindelin wrote:
>>> Well, I consider it a courtesy to the msysGit people to leave it where
>>> it is.
>> Umm. I consider it to be UNACCEPTABLY STUPID to claim "courtesy" if it
>> actually makes something just more irritating to users.
>>
>> I absolutely detest clicking through EULA's or other self-serving crap.
>> I hate software that bothers me with their license details. Nobody reads
>> those things anyway, and an extra click or an extra window I didn't ask
>> for - _especially_ in open source software - is just a bug.
>>
>> Bugs aren't "courtesy". Not to the user, and certainly not to the
>> developer.
>
> It is not a bug. It is a message that tells the Windows user that this is
> GPLed software, and that they are free to copy it. Windows users (and
> developers on Windows are more of users than developers) are often not
> aware of that fact.
Well, maybe so called "Windows pseudo-developers" do not feel welcome to
participate to this particular project? Or maybe this project has not
reached yet the minimum visibility threshold? git has a lot of
contributors on Linux because it is visible there. Do you think all
users of git on Linux systematically contributes?
Don't get me wrong, I am truly thankful for msysgit but, IMHO, if you
produce and publish a free software you should just accept and be glad
that it is used. Otherwise, just don't publish it.
> That is the reason why many Open Source projects do not bother on Linux,
> but do bother on Windows.
And a lot other projects do not bother with this even on Windows and Mac
too.
Regards,
Abdel.
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Catalin Marinas @ 2008-10-06 21:15 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160157.19886.7137.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> + * You can easily 'rebase' your patch stack on top of any other Git
> + branch. (The 'base' of a patch stack is the most recent Git commit
> + that is not an StGit patch.) For example, if you started making
You may want to move the bracket before the dot.
--
Catalin
^ permalink raw reply
* Re: [StGit PATCH 5/6] Refresh the main stg man page
From: Catalin Marinas @ 2008-10-06 21:14 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160157.19886.7137.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> Update the text to reflect what's happened in StGit in the last few
> releases. Also, consistently capitalize the names "Git" and "StGit".
I need to change the websites as well (BTW, I gave you admin rights on
the gna.org project page).
> --- a/Documentation/stg.txt
> +++ b/Documentation/stg.txt
[...]
> + * After making changes to the worktree, you can incorporate the
> + changes into an existing patch; this is called 'refreshing'. You
> + may refresh any patch, not just the topmost one.
I wouldn't advertise the refreshing of "any" patch as it doesn't
always work (it actually fails in a lot of cases). Or at least we
could mention that there are some restrictions.
> + * You can easily 'rebase' your patch stack on top of any other Git
> + branch.
It might be better with something like "on top of a different Git
commit". The first thought when reading the above is that you can move
the patch stack to a different Git branch easily, which is not the
case (you need to cherry-pick the patches).
> + * The patch stack is just some extra metadata attached to regular
> + Git commits, so you can continue to use Git tools along with
> + StGit.
Again, this is with some restrictions (or there aren't any with the
new infrastructure?).
> + Tracking changes from a remote branch, while maintaining local
> + modifications against that branch, possibly with the intent of
> + sending some patches upstream. You can modify your patch stack as
> + much as you want, and when your patches are finally accepted
> + upstream, the permanent recorded Git history will contain just the
> + final sequence of patches, and not the messy sequence of edits that
> + produced them.
Maybe we could mention that the local history is also clean, not only
the upstream tree (though you mention it later in a different hunk).
--
Catalin
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Jeff King @ 2008-10-06 21:03 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006165943.GG8203@spearce.org>
On Mon, Oct 06, 2008 at 09:59:43AM -0700, Shawn O. Pearce wrote:
> * jk/diff-convfilter (Sun Oct 5 17:43:45 2008 -0400) 4 commits
> - diff: add filter for converting binary to text
> - diff: introduce diff.<driver>.binary
> - diff: unify external diff and funcname parsing code
> - t4012: use test_cmp instead of cmp
>
> A general cleanup on how diff drivers are implemented. Its still
> missing documentation updates and tests but doesn't break anything
> current as far as I can tell. It needs more review before it can
> be slated for 'next'.
I should note, too, that this is in direct competition with Matthieu
Moy's "Implementation of a textconv filter for easy custom diff" posted
about a week ago. So if you are reviewing this series, please review
both and decide which you think is more sensible.
-Peff
^ permalink raw reply
* Re: [StGit PATCH 4/6] Add 1.0 TODO items from recent discussion by private mail
From: Catalin Marinas @ 2008-10-06 20:50 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160151.19886.30979.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> +- Convert the remaining commands to the new infrastructure.
> +
> +- Go through the design of the UI and make sure there's nothing hard
> + to change in there that we'll regret later.
> +
> +- Write a user guide. I'm thinking a document on the order of 10-30
> + pages that'll explain why one would want to use StGit, and how.
> +
> +- Make sure the rest of the documentation is in good shape.
Actually, at least for these kind of things we should still keep this
file. We could drop it after 1.0.
--
Catalin
^ permalink raw reply
* Re: What's cooking in git/spearce.git (Oct 2008, #01; Mon, 06)
From: Stephen Haberman @ 2008-10-06 20:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081006165943.GG8203@spearce.org>
> * sh/maint-rebase3 (Sun Oct 5 23:26:52 2008 -0500) 1 commit
> - rebase--interactive: fix parent rewriting for dropped commits
>
> A replacement for sh/maint-intrebase. Its in pu because I have
> gotten 3 different versions of this patch, two of them posted a
> full 4 days after I merged the first version into next. I felt
> burned by the patch author for not keeping up with my tree, so I'm
> not merging the patch to next.
>
> At this point its going to sit in pu until Junio comes back.
> I think the topic needs a few more days to settle to see if the
> patch author is going to submit any more revisions.
All fair enough.
Sorry for not keeping up with your tree--this was the first I heard my
first patch had made it into next, so I kept submitting new ones not
really knowing why they weren't generating feedback. My fault for not
actively looking into the pu/next thing--I'll know what to do next time.
Thanks,
Stephen
^ permalink raw reply
* Re: [StGit PATCH 2/6] Remove TODO items that have already been addressed
From: Catalin Marinas @ 2008-10-06 20:43 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git
In-Reply-To: <20081005160140.19886.92390.stgit@yoghurt>
2008/10/5 Karl Hasselström <kha@treskal.com>:
> TODO | 9 ---------
> 1 files changed, 0 insertions(+), 9 deletions(-)
We could also drop this file entirely since we have a Tasks list on
the gna.org project page.
--
Catalin
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Heikki Orsila @ 2008-10-06 20:11 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, Oct 06, 2008 at 08:01:38PM +0200, Johannes Schindelin wrote:
> It is not a bug. It is a message that tells the Windows user that this is
> GPLed software, and that they are free to copy it. Windows users (and
> developers on Windows are more of users than developers) are often not
> aware of that fact.
>
> That is the reason why many Open Source projects do not bother on Linux,
> but do bother on Windows.
It's pointless and harmful to present any non-relevant information for
users. I simply hate programs that waste my precious seconds. I want it
NOW, not soon. Developers can tell the license if they want to
distribute it, but users do not need it at all.
> So I guess we simply disagree here.
I disagree VIOLENTLY with you. I've been utterly struck with this
Windows crap here.. I spent a day installing stupid trivial software
and answering pointless EULAs. I REALLY REALLY hate extra questions..
This is my 20th reboot..
--
Heikki Orsila
heikki.orsila@iki.fi
http://www.iki.fi/shd
^ permalink raw reply
* Re: how to restrict commit for a repo
From: Miklos Vajna @ 2008-10-06 19:58 UTC (permalink / raw)
To: Dilip M; +Cc: Git Mailing List
In-Reply-To: <c94f8e120810061012p29210247sfd3c1b3c05e871ee@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Mon, Oct 06, 2008 at 10:42:06PM +0530, Dilip M <dilipm79@gmail.com> wrote:
> > Have you seen contrib/hooks/update-paranoid?
>
> Miklos, I am totally new to this tool ( don't know SVN too).
That's good, since your mind is clear yet. :)
> Can you please consider giving some more info...or guiding me to some
> good links...:)
>
> Thanks in advance..
In general, I would suggest reading the user manual and everyday.txt,
both are under Documentation/.
Second, read man githooks, and then you'll understand how to use the
mentioned hook.
HTH
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: David Bryson @ 2008-10-06 19:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0810061610400.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes,
On Mon, Oct 06, 2008 at 04:13:17PM +0200 or thereabouts, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 2 Oct 2008, David Bryson wrote:
>
> >
> > Signed-off-by: David Bryson <david@statichacks.org>
> >
> > I tried to keep with the naming/coding conventions that I found in
> > remote.c. Feedback welcome.
> >
> > ---
>
> Usually this comment goes after the --- but other than that, the form is
> as perfect as you can wish for.
I see, still trying to remember all the little tricks for proper
submission, thanks.
> > @@ -314,15 +315,15 @@ static int handle_config(const char *key, const char *value, void *cb)
> > return 0;
> > branch = make_branch(name, subkey - name);
> > if (!strcmp(subkey, ".remote")) {
> > - if (!value)
> > - return config_error_nonbool(key);
> > - branch->remote_name = xstrdup(value);
> > + if (git_config_string(&v, key, value) )
> > + return -1;
> > + branch->remote_name = v;
>
> What is the reason not to write
>
> if (git_config_string(&branch->remote_name, key, value))
> return -1;
The only reason is it did not come to mind ;-) But it does make the
statement somewhat clearer.
> ? (Also note that we do not like the space between the two closing
> parentheses.)
An oversight to be sure and not intentional, I read the CodingGuidelines
very carefully ;-)
Dave
^ permalink raw reply
* Re: [PATCH] Use "git_config_string" to simplify "remote.c" code in "handle_config"
From: David Bryson @ 2008-10-06 19:49 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0810041546w5eed8859vd8266bb66425ebd3@mail.gmail.com>
On Sun, Oct 05, 2008 at 12:46:29AM +0200 or thereabouts, Alex Riesen wrote:
> >
>
> You can redeclare of the variable in the contexts where
> it is used and not even rename it: it is close to its users then.
I'm not sure I understand entirely, care to elaborate a bit more ?
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Linus Torvalds @ 2008-10-06 19:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.DEB.1.00.0810061959280.22125@pacific.mpi-cbg.de.mpi-cbg.de>
On Mon, 6 Oct 2008, Johannes Schindelin wrote:
>
> It is not a bug.
If it's unwanted functionality, that's a bug. That's kind of the whole
(and only) difference between "bug" and "feature". Do people want it?
And Petr made it clear that he didn't want it. And I can certainly
understand why - so it's not just some confused user. As such, it's
clearly not a feature, and is clearly a bug.
Linus
^ permalink raw reply
* Re: [QGIT PATCH] Rework the commit confirmation box a bit
From: Marco Costalba @ 2008-10-06 19:03 UTC (permalink / raw)
To: Abdelrazak Younes; +Cc: Git Mailing List
In-Reply-To: <48E9D659.1090503@lyx.org>
On Mon, Oct 6, 2008 at 11:11 AM, Abdelrazak Younes <younes@lyx.org> wrote:
> The problem was that the dialog was too big for my whenever too many files
> were changed. Now, the list of changed files is only shown whenever they are
> less than 20; otherwise it is shown in the detailed text accessible though
> the 'Show Detail' button.
> ---
Thanks,
patch applied and pushed.
Marco
^ permalink raw reply
* Re: git://oss.sgi.com broke
From: Daniel Barkalow @ 2008-10-06 17:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, xfs-masters, git
In-Reply-To: <alpine.LFD.2.00.0810061005540.3208@nehalem.linux-foundation.org>
On Mon, 6 Oct 2008, Linus Torvalds wrote:
> On Fri, 3 Oct 2008, Andrew Morton wrote:
> >
> > y:/usr/src/git26> git --version
> > git version 1.5.6.rc0
> >
> > y:/usr/src/git26> cat .git/branches/git-xfs
> > git://oss.sgi.com:8090/xfs/xfs-2.6.git#master
>
> Hmm. That's the really old and deprecated branch format.
>
> I'm getting a "Connection refused" from oss.sgi.com, and I think there's
> possibly something broken there, but quite independently of that, maybe we
> can try to teach you another way to set up remote branches?
>
> In your .git/config file, use
>
> [remote "git-xfs"]
> url = git://oss.sgi.com:8090/xfs/xfs-2.6.git
> fetch = master
>
> because the whole .git/branches/<branch-name> thing is fairly deprecated,
> and cannot handle some things that the .git/config file format can (like
> saying where to fetch into, or how to push back etc).
I think Andrew convinced us to undeprecate that format, because he wants
to be able to configure each branch with one line in a separate file. In
any case, remote.c takes care of these things seemlessly.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [msysGit] [FYI][PATCH] Customizing the WinGit installer
From: Robin Burchell @ 2008-10-06 17:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061031380.3208@nehalem.linux-foundation.org>
On Mon, Oct 6, 2008 at 6:34 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I absolutely detest clicking through EULA's or other self-serving crap. I
> hate software that bothers me with their license details. Nobody reads
> those things anyway, and an extra click or an extra window I didn't ask
> for - _especially_ in open source software - is just a bug.
>
I'll just jump in and add my (admittedly inexperienced) $0.02 -
namely, my confusion as to why the GPL would be displayed in place of
a EULA when ...it's not a EULA. It is not about how the software may
be used at all:
Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope. The act of running
the Program is not restricted, and the output from the Program is
covered only if its contents constitute a work based on the Program
(independent of having been made by running the Program). Whether that
is true depends on what the Program does.
^ permalink raw reply
* Re: [FYI][PATCH] Customizing the WinGit installer
From: Johannes Schindelin @ 2008-10-06 18:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jakub Narebski, Petr Baudis, msysgit, git
In-Reply-To: <alpine.LFD.2.00.0810061031380.3208@nehalem.linux-foundation.org>
Hi,
On Mon, 6 Oct 2008, Linus Torvalds wrote:
> On Mon, 6 Oct 2008, Johannes Schindelin wrote:
> >
> > Well, I consider it a courtesy to the msysGit people to leave it where
> > it is.
>
> Umm. I consider it to be UNACCEPTABLY STUPID to claim "courtesy" if it
> actually makes something just more irritating to users.
>
> I absolutely detest clicking through EULA's or other self-serving crap.
> I hate software that bothers me with their license details. Nobody reads
> those things anyway, and an extra click or an extra window I didn't ask
> for - _especially_ in open source software - is just a bug.
>
> Bugs aren't "courtesy". Not to the user, and certainly not to the
> developer.
It is not a bug. It is a message that tells the Windows user that this is
GPLed software, and that they are free to copy it. Windows users (and
developers on Windows are more of users than developers) are often not
aware of that fact.
That is the reason why many Open Source projects do not bother on Linux,
but do bother on Windows.
So I guess we simply disagree here.
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