* Re: [PATCH] git push --track
From: Johannes Schindelin @ 2010-01-14 10:31 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Rudolf Polzer, git
In-Reply-To: <20100114154154.6117@nanako3.lavabit.com>
Hi,
On Thu, 14 Jan 2010, Nanako Shiraishi wrote:
> Quoting Rudolf Polzer <divVerent@alientrap.org>
>
> > I'd like a feature to automatically "transform" a non-tracking local
> > branch into a tracking branch on push. A patch to do that is attached.
>
> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390
Thank you for looking up that reference.
Do you remember what the outcome was? (Peff mentioned that there was some
talk about putting this code into transport.c and some needed
restructurings, but I do not remember the details, and I did not have time
to follow the development of that file in the recent months.)
Ciao,
Dscho
^ permalink raw reply
* Re: Migrating from Serena PVCS to GIT
From: Peter Krefting @ 2010-01-14 9:51 UTC (permalink / raw)
To: Rivka Pollack; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.1001141007260.15144@ds9.cixit.se>
Following up my own reply:
> There is a script for PVCS-to-RCS export in the CVS source archives (I
> needed to hack the scripts a bit to get them to run properly,
> unfortunately I do not have access to those changes).
IIRC, the changes I needed to make was to ensure that the files did not get
their keyword expanded again by RCS (adding -ko mode; this also survives
into Git), since the revision numbers are off-by-one in RCS compared to PVCS
(RCS starts at 1.1, PVCS at 1.0). I also had to extend the list of binary
file types in the PVCS-to-RCS script to cover all the binary files that were
checked in.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Using GIT with FrameMaker
From: Matthieu Moy @ 2010-01-14 9:33 UTC (permalink / raw)
To: Rivka Pollack; +Cc: git
In-Reply-To: <loom.20100114T094846-797@post.gmane.org>
Rivka Pollack <Rivka_P1@verifone.com> writes:
> Hi,
> My Technical Documentation team has recently been informed that we are to be
> moving to GIT for our version control.
> We will be working in GIT GUI or GIT extensions.
> I see, however, that you cannot properly use the "diff" view properly with the
> FrameMaker files, but only, from what I can tell, .txt, and .html.
Not just .txt and .html. Anything that looks like text (i.e. anything
that can be opened in a text editor and looks good in it).
> Is there a good way to work with GIT from FrameMaker?
FrameMaker, I have no idea. But Git has two things that can help you:
* External diff engine: read about GIT_EXTERNAL_DIFF in
http://www.kernel.org/pub/software/scm/git/docs/v1.0.13/git-diff-files.html
and look for "Defining an external diff driver" in
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
Roughly, if FrameMaker has a way to compare two documents, then Git
can call it automatically.
* Text Converters: Read the section "Performing text diffs of binary
files" in
http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
Roughly: if you have a way to display the content of your framemaker
files as text, then Git can call this, and then show a textual diff
of your document.
In this page http://www-verimag.imag.fr/~moy/opendocument/ I explain
how to do that with OpenDocument files (OpenOffice & friends). If
FrameMaker provides the relevant tools, it shouldn't be hard to adapt.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 00/18] rebase -i: For pure fixups, do not start log message editor
From: Junio C Hamano @ 2010-01-14 9:17 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Johannes.Schindelin
In-Reply-To: <cover.1263447037.git.mhagger@alum.mit.edu>
Very nicely done and the series was a pleasure to read, even though I
didn't read some of them very deeply and might have missed some subtle
details outside the context of the patch.
Thanks.
^ permalink raw reply
* Re: [PATCH 09/18] t3404: Test the commit count in commit messages generated by "rebase -i"
From: Johannes Sixt @ 2010-01-14 9:16 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <4B4EDD02.70603@alum.mit.edu>
Michael Haggerty schrieb:
> True, an empty $EXPECT_HEADER_COUNT is not an error. But I think the
> form (A || B || C) is correct anyway...
Very true. I haven't had my morning coffee, yet...
-- Hannes
^ permalink raw reply
* Re: Migrating from Serena PVCS to GIT
From: Peter Krefting @ 2010-01-14 9:10 UTC (permalink / raw)
To: Rivka Pollack; +Cc: Git Mailing List
In-Reply-To: <loom.20100114T095059-276@post.gmane.org>
Rivka Pollack:
> Is there a simple way to migrate from Serena PVCS, with all of our older,
> versioned, documentation, into GIT repositories?
The only more-or-less reliable export from PVCS that I have found is to RCS.
There is a script for PVCS-to-RCS export in the CVS source archives (I
needed to hack the scripts a bit to get them to run properly, unfortunately
I do not have access to those changes). It needs to be run on a machine
that has both PVCS and RCS binaries installed, and it needs to check out
every revision for every file, so it does take some time to run.
After doing that, I moved the RCS files to a CVS-like directory layout and
imported them into Git using one of the CVS-to-Git migration tools.
A tedious process, but it can be done.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 10/18] rebase -i: Improve consistency of commit count in generated commit messages
From: Michael Haggerty @ 2010-01-14 9:05 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <4B4ECD9E.5000707@viscovery.net>
Johannes Sixt wrote:
> Michael Haggerty schrieb:
>> Use the numeral "2" instead of the word "two" when two commits are
>> being interactively squashed. This makes the treatment consistent
>> with that for higher numbers of commits.
>
> Huh? This is just code churn: consistency is not an advantage here.
>
> Oh...wait... The next patch needs it this way. Couldn't you have justified
> it with "In a subsequent change, we will extract the numeral and use it in
> an expression."
In the non-git universe, consistency in the user interface *is*
considered an advantage :-) But I will be happy to add your suggested
*second* justification for the change in v2.
Michael
^ permalink raw reply
* Re: [PATCH 09/18] t3404: Test the commit count in commit messages generated by "rebase -i"
From: Michael Haggerty @ 2010-01-14 8:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <4B4ECB76.3030009@viscovery.net>
Johannes Sixt wrote:
> Michael Haggerty schrieb:
>> + test -z "$EXPECT_HEADER_COUNT" ||
>> + test "$EXPECT_HEADER_COUNT" = $(sed -n '1s/^# This is a combination of \(.*\) commits\./\1/p' < "$1") ||
>> + exit
>
> Is an empty $EXPECT_HEADER_COUNT an error? I suppose it isn't; therefore,
> you must put the second 'test' and the 'exit' in a brace group.
True, an empty $EXPECT_HEADER_COUNT is not an error. But I think the
form (A || B || C) is correct anyway, because if $EXPECT_HEADER_COUNT is
empty, then A is successful, and neither B nor C are executed, and
execution falls through to the later tests.
> You should also put the $(sed) in double-quotes.
Yes, thanks. I'll include it in the next version.
Michael
^ permalink raw reply
* Using GIT with FrameMaker
From: Rivka Pollack @ 2010-01-14 8:50 UTC (permalink / raw)
To: git
Hi,
My Technical Documentation team has recently been informed that we are to be
moving to GIT for our version control.
We will be working in GIT GUI or GIT extensions.
I see, however, that you cannot properly use the "diff" view properly with the
FrameMaker files, but only, from what I can tell, .txt, and .html.
Is there a good way to work with GIT from FrameMaker?
Thanks
^ permalink raw reply
* Migrating from Serena PVCS to GIT
From: Rivka Pollack @ 2010-01-14 8:54 UTC (permalink / raw)
To: git
Is there a simple way to migrate from Serena PVCS, with all of our older,
versioned, documentation, into GIT repositories?
Thanks.
^ permalink raw reply
* Re: [PATCH 0/7] Gitweb caching v4
From: Junio C Hamano @ 2010-01-14 8:54 UTC (permalink / raw)
To: J.H.; +Cc: Junio C Hamano, git
In-Reply-To: <4B4EDA39.1020400@eaglescrag.net>
"J.H." <warthog9@eaglescrag.net> writes:
> Junio,
>
> I'd suggest using v5 vs. v4 as there was a couple of issues I discovered
> with v4 today.
Yeah, I just noticed. I was away from the keyboard for the better part of
evening.
^ permalink raw reply
* Re: [RFC 0/2] Git-over-TLS (gits://) client side support
From: Ilari Liusvaara @ 2010-01-14 8:51 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Andreas Krey, Nguyen Thai Ngoc Duy, git
In-Reply-To: <32541b131001131551m38ff02acpdd08d9f0562ac84d@mail.gmail.com>
On Wed, Jan 13, 2010 at 06:51:03PM -0500, Avery Pennarun wrote:
> On Wed, Jan 13, 2010 at 6:00 PM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> > On Wed, Jan 13, 2010 at 05:03:45PM -0500, Avery Pennarun wrote:
> >
> > No client-side fallbacks, key auth works pseudonymously. That takes
> > care of them pretty well.
>
> Perhaps I'm being dense, but I don't understand what you mean by
> either of those.
The client tries only one auth method instead of potentially trying
multiple. Witness the 'use verbose mode and check if it uses the key'
type stuff.
With keypair auth, the server can accept arbitrary (valid) keypair,
but only limited set have special priviledges -> Cuts down significantly
on "why this doesn't accept the key" problems (the keyid is usually
printed on denied access).
> >> If you solve your main
> >> annoyances with ssh, how do you know you won't introduce any new
> >> annoying failure modes?
> >
> > Ensuring that at least some information make back to client (presuably
> > enough to figure out the problem).
>
> Unfortunately revealing information like that is a compromise; it
> helps attackers as well as legitimate users. It's the same reason
> login prints "invalid username or password" instead of choosing
> between "invalid username" and "invalid password."
Yeah. Sometimes one must chose balance between being helpful to users
and being helpful for attackers.
> >> *Why* can't ssh be fixed to solve the problem?
> >
> > Client side fallbacks (may be desired or not!), service not being
> > able to intervene on wheither to allow client or not in case of
> > keypair auth.
>
> I don't understand that answer. Couldn't ssh be patched to do
> whatever you want? Particularly if it's just better (optional)
> diagnostics, you'd think someone would accept the patch for that.
OpenSSH? With the level of paranoia in it, I'd say good luck. And
it's not just client, its the server also (and especially the
server).
> >> Will I have to generate and manage yet another new set of
> >> keys to use the new system?
> >
> > Yes.
>
> Ouch.
Well, usually that means one keypair to generate and exchanging
keyids.
And if you host the repo system too, you would get second key anyway
(and SSH is not too good at handling multiple keys).
> > Well, if you like SSH more, then use ssh://...
>
> I'm just looking for a justification for why I *shouldn't* like ssh
> more. Is the only reason the fact that it might be easier to
> initially configure the key exchange?
And besides, gits:// is for host multiple repos type stuff, not for
private repos on your account (use the ssh:// for those, and there the
failure modes of SSH matter much less).
-Ilari
^ permalink raw reply
* Re: [PATCH 0/7] Gitweb caching v4
From: J.H. @ 2010-01-14 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmy0hhyer.fsf@alter.siamese.dyndns.org>
Junio,
I'd suggest using v5 vs. v4 as there was a couple of issues I discovered
with v4 today.
- John 'Warthog9' Hawley
On 01/14/2010 12:40 AM, Junio C Hamano wrote:
> Will replace what was queued on 'pu'.
>
> For [3/7], I had to resolve conflicts in Makefile as it seemt to have been
> based on a bit older one. When I push the result out, please verify.
>
> The result merged to 'pu' seems to break t9500 but I didn't look very
> carefully.
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Test t5560: Fix test when run with dash
From: Junio C Hamano @ 2010-01-14 8:41 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Michael Haggerty, git, Shawn O. Pearce
In-Reply-To: <1263452477-15250-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> dash is more finicky than some shells and this change seems to make it
> happier.
"Finicky" won't help other people to learn what to avoid making the same
mistake in the future. Please spell the problem out more explicitly.
I think the issue is that some shells do not like the "Run this command
(and only this command) under these environment variable settings"
VAR1=VAL1 VAR2=VAL2 command
if "command" is a shell function.
Does that match your understanding of the problem?
^ permalink raw reply
* Re: [PATCH 0/7] Gitweb caching v4
From: Junio C Hamano @ 2010-01-14 8:40 UTC (permalink / raw)
To: John 'Warthog9' Hawley; +Cc: git
In-Reply-To: <1263375282-15508-1-git-send-email-warthog9@eaglescrag.net>
Will replace what was queued on 'pu'.
For [3/7], I had to resolve conflicts in Makefile as it seemt to have been
based on a bit older one. When I push the result out, please verify.
The result merged to 'pu' seems to break t9500 but I didn't look very
carefully.
^ permalink raw reply
* Re: [PATCH] Show submodules as modified when they contain a dirty work tree
From: Jens Lehmann @ 2010-01-14 8:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Johannes Schindelin, Shawn O. Pearce,
Heiko Voigt, Lars Hjemli
In-Reply-To: <7v6375lkpj.fsf@alter.siamese.dyndns.org>
Am 13.01.2010 23:10, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> I had to squash in '#include "submodule.h"' in diff-lib.c just after it
> includes "refs.h", though.
Sorry, i seem to repeatedly have missed the compiler warning :-(
> And a patch to add:
>
>>> * It doesn't give detailed output when doing a "git diff* -p" with or
>>> without the --submodule option. It should show something like
>>>
>>> diff --git a/sub b/sub
>>> index 5431f52..3f35670 160000
>>> --- a/sub
>>> +++ b/sub
>>> @@ -1 +1 @@
>>> -Subproject commit 5431f529197f3831cdfbba1354a819a79f948f6f
>>> +Subproject commit 3f356705649b5d566d97ff843cf193359229a453-dirty
>>>
>
> would look like the attached.
Thanks!
> I think a reasonable next step would be
>
> - Move the check for your condition (c) that we dropped from this round
> to wt-status.c;
>
> - Add wt_status_print_dangling_submodules() to wt-status.c, and use the
> above logic to produce a section "Submodules with Dangling HEAD" or
> something.
>
> - Call it in wt_status_print(), immediately before we check s->verbose
> and show the patch text under -v option. "git status" now will warn
> about the condition (c).
>
> - Add a similar wt_shortstatus_print_dangling_submodules() and call it at
> the end of wt_shortstatus_print().
>
> - Update is_submodule_modified() in your patch thats reads the output
> from "status --porcelain", to *ignore* information about dangling
> submodules. As we discussed, dangling submodules may be something the
> user cares about, but that is not something "diff" should.
Great, i will send patches when i have something to show.
^ permalink raw reply
* Re: [PATCH] Test t5560: Fix test when run with dash
From: Michael Haggerty @ 2010-01-14 8:23 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <1263452477-15250-1-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt wrote:
> dash is more finicky than some shells and this change seems to make it
> happier.
>
> Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
> Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> ---
> Michael, thanks for the report.
>
> Ubuntu's /bin/sh is dash, which I had not tested with. Installing
> dash on my machine, I was able to reproduce and this patch fixes the
> problem for me.
>
> Could you please see if this works for you?
> [...]
Yes, that fixes it. Thanks!
Michael
^ permalink raw reply
* Re: [PATCH 15/18] rebase -i: Change function make_squash_message into update_squash_message
From: Johannes Sixt @ 2010-01-14 8:20 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <784d63d686a82b93a29531d3079aadbe83258d9f.1263447038.git.mhagger@alum.mit.edu>
Michael Haggerty schrieb:
> Alter the file $SQUASH_MSG in place rather than outputting the new
> message then juggling it around. Change the function name
> accordingly.
Code churn... Oh...wait... (You get the point ;)
-- Hannes
^ permalink raw reply
* Re: [PATCH 10/18] rebase -i: Improve consistency of commit count in generated commit messages
From: Johannes Sixt @ 2010-01-14 7:54 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <1e03c6ff51ca0e6da4c19da014523f01a27b1579.1263447038.git.mhagger@alum.mit.edu>
Michael Haggerty schrieb:
> Use the numeral "2" instead of the word "two" when two commits are
> being interactively squashed. This makes the treatment consistent
> with that for higher numbers of commits.
Huh? This is just code churn: consistency is not an advantage here.
Oh...wait... The next patch needs it this way. Couldn't you have justified
it with "In a subsequent change, we will extract the numeral and use it in
an expression."
-- Hannes
^ permalink raw reply
* Re: [PATCH 09/18] t3404: Test the commit count in commit messages generated by "rebase -i"
From: Johannes Sixt @ 2010-01-14 7:44 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <c3ec064944c4c5e6a3eba5c71e8956fe8bceb3ad.1263447037.git.mhagger@alum.mit.edu>
Michael Haggerty schrieb:
> + test -z "$EXPECT_HEADER_COUNT" ||
> + test "$EXPECT_HEADER_COUNT" = $(sed -n '1s/^# This is a combination of \(.*\) commits\./\1/p' < "$1") ||
> + exit
Is an empty $EXPECT_HEADER_COUNT an error? I suppose it isn't; therefore,
you must put the second 'test' and the 'exit' in a brace group.
You should also put the $(sed) in double-quotes.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-14 7:00 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: Ilari Liusvaara, Matthieu Moy, Miles Bader, Johannes Schindelin,
git
In-Reply-To: <be6fef0d1001132121w4e25c7f0j760d71c136012401@mail.gmail.com>
On Thu, Jan 14, 2010 at 01:21:17PM +0800, Tay Ray Chuan wrote:
> Hi,
>
> generally, it would be better if you could add some tests for this.
>
> If I'm not wrong, the place to put it would be t5516-fetch-push.sh.
Can add that, but it seems like it won't go in anyway from the discussion here,
so it's probably not worth working on it. Sad.
> On Wed, Jan 13, 2010 at 11:55 PM, Rudolf Polzer <divVerent@alientrap.org> wrote:
> > On Wed, 13 Jan 2010 16:43:10 +0100, Ilari Liusvaara
> > <ilari.liusvaara@elisanet.fi> wrote:
>
> please don't drop people from the Cc list - especially when you're
> replying to somebody!
I did not drop anyone, but simply replied from my newsreader. I really don't
want to subscribe to a mailing list and then get hundreds of emails a day.
> > From 123598516c7d4e1f83591e8dae64e2c76dc87c90 Mon Sep 17 00:00:00 2001
> > From: Rudolf Polzer <divVerent@alientrap.org>
> > Date: Wed, 13 Jan 2010 16:42:04 +0100
> > Subject: [PATCH 1/2] Add a feature "git push --track" to automatically make
> > the pushed branches tracking
>
> Each patch should be sent out in its own mail. (As Matthieu has
> recommended, you should check out Documentation/SubmittingPatches.)
So, using a newsreader is not accepted practice? Why is the mailing list on a
newsgroup then?
> > static const char * const push_usage[] = {
> > @@ -115,6 +116,36 @@ static int push_with_options(struct transport
> > *transport, int flags)
> > fprintf(stderr, "Pushing to %s\n", transport->url);
> > err = transport_push(transport, refspec_nr, refspec, flags,
> > &nonfastforward);
> > + if (err == 0 && flags & TRANSPORT_PUSH_TRACK) {
> > + struct ref *remote_refs =
> > + transport->get_refs_list(transport, 1);
> > + struct ref *local_refs = get_local_heads();
> > + int match_flags = 0;
> > + if (flags & TRANSPORT_PUSH_ALL)
> > + match_flags |= MATCH_REFS_ALL;
> > + if (flags & TRANSPORT_PUSH_MIRROR)
> > + match_flags |= MATCH_REFS_MIRROR;
> > + if(!(flags & TRANSPORT_PUSH_DRY_RUN))
> > + if(!match_refs(local_refs, &remote_refs, refspec_nr,
> > refspec,
> > + match_flags)) {
>
> It would be better if you can move this to
> transport.c::transport_push(). It repeats what's already there, so you
> don't have to configure match_flags, nor call match_refs, etc.
Then I have to duplicate it in the rsync specific push code too. Otherwise,
agreed.
> > + struct ref *next = remote_refs;
> > + while(next) {
> > [snip]
> > + next = next->next;
>
> In most places, this is done like this:
>
> struct ref* ref;
> for (ref = remote_refs; ref; ref = ref->next) {
> ...
> }
Sure, could do that too, I got this loop from the loop that frees a ref list.
Best regards,
Rudolf
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-14 7:01 UTC (permalink / raw)
To: Miles Bader; +Cc: git
In-Reply-To: <871vht7cs2.fsf@catnip.gol.com>
On Thu, Jan 14, 2010 at 09:25:49AM +0900, Miles Bader wrote:
> "Rudolf Polzer" <divVerent@alientrap.org> writes:
> > I'd like a feature to automatically "transform" a non-tracking local
> > branch into a tracking branch on push. A patch to do that is attached.
>
> Yay!!
>
> I've wanted this for a long time, but discussions about it always seem
> to end up petering out...
>
> > git branch mybranch
> > git checkout mybranch
> > ...
> > git push --track origin mybranch:mybranch
>
> Does it default to the current branch so you can just say "git push --track origin"?
It does the very same decisions as push. Basically, it is "whatever got pushed,
mark as tracking".
Best regards,
Rudolf
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-14 7:03 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d1001131727r128c7727td2b948018d308719@mail.gmail.com>
On Thu, Jan 14, 2010 at 09:27:26AM +0800, Tay Ray Chuan wrote:
> before I put up my comments on the patch, I wonder if git-push is the
> best place to add this feature, as git-push usually deals with
> "pushing" data to another repo.
>
> I think git-branch would be a better place to do this.
I think git-branch can already do this: after pushing, you can do git branch -f
--track origin/mybranch.
But the goal of this is to postponing the decision to track to the push time,
and adding as little as possible extra commands/options to do this.
^ permalink raw reply
* Re: [PATCH] git push --track
From: Jeff King @ 2010-01-14 7:16 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git
In-Reply-To: <op.u6haiiiog402ra@nb-04>
On Wed, Jan 13, 2010 at 04:55:20PM +0100, Rudolf Polzer wrote:
> >- Should the tracking be set up even if only part of ref update suceeded
> >(for those that succeeded), not requiring all to succeed?
>
> Good point, but I simply see no clean way to set it up for the
> succeeded refs. Would be a nice idea for improvement of this.
I don't think it's that hard. In fact, I did a preliminary patch for it
about a year ago:
http://article.gmane.org/gmane.comp.version-control.git/107750
That patch was held up because there were a lot of cleanups needed in
transport.c before it would make sense (read the whole thread for
details). I think most of those cleanups have happened in the meantime,
so it would be pretty straightforward to use the same setup_tracking()
function and just call it from the right spot in transport.c. But I
haven't actually looked at this topic since the above-referenced thread.
-Peff
^ permalink raw reply
* Re: [PATCH] git push --track
From: Rudolf Polzer @ 2010-01-14 7:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20100114154154.6117@nanako3.lavabit.com>
On Thu, Jan 14, 2010 at 03:41:54PM +0900, Nanako Shiraishi wrote:
> Quoting Rudolf Polzer <divVerent@alientrap.org>
>
> > I'd like a feature to automatically "transform" a non-tracking local
> > branch into a tracking branch on push. A patch to do that is attached.
>
> How well does this take earlier discussions on the same topic into account? For example, did you study the design discussion in
> http://thread.gmane.org/gmane.comp.version-control.git/135325/focus=135390
I don't really think this has much to do with the other. git branch
--will-track still means one needs to know it at branch setup time, and git
pull --remember still means one needs to type way more stuff than with a simple
push --track.
But well, given the discussion here I see the feature is essentially rejected,
and already was rejected a previous time. Will probably forget about this and
make a shell script that does for ME what I want.
Best regards,
Rudolf
^ 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