* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 20:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Johannes Sixt, Jay Soffian, Git Mailing List
In-Reply-To: <7vhc1pai84.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 19, 2009 at 04:02:19AM -0700, Junio C Hamano wrote:
> > Do we really want an API for that? Calling qsort() directly should be
> > obvious enough, no?
>
> I think so. If it were done like this (notice the lack of double
> indirection in the cmp_fn signature):
>
> typedef int string_list_item_cmp_fn(const struct string_list_item *, const struct string_list_item *);
>
> void sort_string_list_with_fn(struct string_list *list, string_list_item_cmp_fn *);
>
> it would have made more sense, though.
IIRC, that is actually not valid C according to the standard (that is,
even though a void* can be implicitly assigned to any other pointer, a
function taking a void* and a function taking another pointer do not
necessarily have the same function signature or calling conventions).
Which is why cmp_items in string-list.c already does the indirection.
That being said, I think this is probably one of those cases where it
works fine on any sane platform that we care about and we can choose to
ignore the standard.
Actually, I think an even nicer API would be to give a function that
_just_ compares the util fields; string_list_sort() would sort on the
"string" fields, and only call the util cmp to sort entries with equal
strings. Sadly, because qsort lacks a slot for extra data to pass to the
callback, implementing this ends up with a global variable:
static int (*cmp_util)(const void *, const void *);
int cmp_items(const void *a, const void *b)
{
const struct string_list_item *one = a;
const struct string_list_item *two = b;
int cmp = strcmp(one->string, two->string);
return cmp ? cmp : cmp_util(one->util, b->util);
}
int sort_string_list_with_util(struct string_list *list,
int (*fn)(const void *, const void *))
{
cmp_util = fn;
qsort(list->items, list->nr, sizeof(*list->items), cmp_items);
}
If only C had closures. ;)
But this is really getting beyond the issue at hand. I can submit a
finalized patch; just let me know how you prefer it.
-Peff
^ permalink raw reply
* git-svn and incorrect working copy file timestamps?
From: Derek Mahar @ 2009-03-19 19:54 UTC (permalink / raw)
To: git
Should "git svn" not preserve the file timestamps of the original commit tree
in the working copy? Using Git 1.6.2.1, built from source, I find that "git
svn clone" sets the file timestamps in the working copy to the current date.
I expected the timestamps to match those of the tree as it was originally
committed. I get this result using both Cygwin and Crunchbang Linux 8.10.02
(an Ubuntu derivative).
Derek
--
View this message in context: http://n2.nabble.com/git-svn-and-incorrect-working-copy-file-timestamps--tp2505059p2505059.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Jeff King @ 2009-03-19 19:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Jay Soffian, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0903191135530.10279@pacific.mpi-cbg.de>
On Thu, Mar 19, 2009 at 11:36:50AM +0100, Johannes Schindelin wrote:
> > +void sort_string_list_with_fn(struct string_list *list,
> > + int (*fn)(const void *, const void *))
> > +{
> > + qsort(list->items, list->nr, sizeof(*list->items), fn);
> > +}
> > +
>
> Do we really want an API for that? Calling qsort() directly should be
> obvious enough, no?
I'm fine with that, too. I was just encapsulating out of habit. But if
it is normal to peek directly at list->nr and list->items, then calling
qsort directly is fine.
-Peff
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Eric Raible @ 2009-03-19 19:52 UTC (permalink / raw)
To: markus.heidelberg; +Cc: Santi Béjar, Eric Raible, git
In-Reply-To: <200903192032.42117.markus.heidelberg@web.de>
2009/3/19 Markus Heidelberg <markus.heidelberg@web.de>:
>
> If scrolling through a history with many branches (so many parallel
> lines) like git.git, colors help you to follow a particular line.
>
> I don't find it easy to follow a line in a PCB, where you normally don't
> have colors :)
>
> Markus
I find it easier to simply click on the line and then click the parent
in the lower window. Which I'm only mentioning b.c. others might
not realize that it's possible.
The meta question is: anyone know of any gitk/git gui documentation
aside from Junio's excellent "Fun with msysgit 1.6.1 preview"
(http://gitster.livejournal.com/24080.html)?
Anything additional would be useful in my quest to get $dayjob to switch to git.
- Eric
^ permalink raw reply
* Re: [PATCH 08/10] t2200, t7004: Avoid glob pattern that also matches files
From: Johannes Sixt @ 2009-03-19 19:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i2mbap2.fsf@gitster.siamese.dyndns.org>
On Donnerstag, 19. März 2009, Junio C Hamano wrote:
> Johannes Sixt <j6t@kdbg.org> writes:
> > On Windows, there is an unfortunate interaction between the MSYS bash and
> > git's command line processing:
> >
> > - Since Windows's CMD does not do the wildcard expansion, but passes
> > arguments like path* through to the programs, the programs must do the
> > expansion themselves. This happens in the startup code before main() is
> > entered.
> >
> > - bash, however, passes the argument "path*" to git, assuming that git
> > will see the unquoted word unchanged as a single argument.
> >
> > But actually git expands the unquoted word before main() is entered.
>
> Doesn't this mean on Windows, the glob pathspec git supports is not useful
> at all?
No, it is still useful. There is a difference if I say
git add "*a*"
from bash or from Windows's CMD. The latter passes the argument to git with
the dquotes; the startup code removes them and does not expand the wildcard.
But if bash invokes the command, bash removes the quotes, so that the startup
code only sees *a* and does the expansion.
> > In t2200, not all names that the test case is interested in exist as
> > files at the time when 'git ls-files' is invoked. git expands "path?" to
> > only the subset of files the exist, and only that subset was listed, so
> > that the test failed. We now list all interesting paths explicitly.
>
> But that conversion misses the whole point of that particular test,
> doesn't it? It wants to see path2 that was unmerged and existed only in
> the index but not in the work tree has disappeared, while the similarly
> unmerged path1 resolved after "add -u". IOW, you are not testing that
> "add -u" notices a removal of path2 from the work tree anymore.
I see. Then I'll just add path2 to the list, OK? It still passes the test.
-- Hannes
^ permalink raw reply
* Re: keeping track of what a branch is for
From: Junio C Hamano @ 2009-03-19 19:46 UTC (permalink / raw)
To: E R; +Cc: git
In-Reply-To: <3a69fa7c0903191036u24bbf613had88dbebb24335c4@mail.gmail.com>
E R <pc88mxer@gmail.com> writes:
> Ok - here's another one...
>
> I've started to create a lot of branches (like one per feature I'm
> working on), but I'm starting to have trouble keeping track of what
> each branch is for. Also, I'd like to keep track of a todo list for
> each branch.
I have to admit that I do face this exact problem in managing git.git
itself, which is an example of a topic-heavy project management, and I
cannot say I have managed to solve it within the canned set of tools git
gives, but the workflow I established makes it manageable, and it consists
of three ingredients:
(1) Name your (eh, "my") branch just like you name your function.
You probably learned in programming 101 course the importance of
giving a good name to your functions. The same principle applies.
When I see kb/checkout-optim branch, I know it is about optimizing
the checkout command, and it came from Kjetil Barvik. I can tell
that jc/maint-1.6.0-read-tree-overlay is about the bugfix to the
"overlay" feature of read-tree command, and the fix would apply as
far back as the 1.6.0.X series, not just the current maintenance.
(2) I also use a few custom scripts (Meta/WC, Meta/git-topic.perl and
Meta/UWC) to manage "What's cooking" messages you see on the list.
Probably some of the computations git-topic.perl does can be more
generalized (it currently relies on the convention to name topic
branches with a slash in their names, and you have up to three
integration branches such as master, next and pu).
After accumulating new patches on top of topics and merging more
topics to integration branches (such as master and next), I run
Meta/WC which in turn runs Meta/UWC to read the last issue of "What's
cooking", and the raw material that should go in the next issue of
the message (generated by Meta/git-topic.perl), and the comments on
each topic in the last issue is merged to produce the draft of the
next issue. I add further text to it to describe new deveolopment to
existing topics and comment on new topics before sending it out, and
another cycle begins.
(3) I also have a custom script Meta/GRADUATED to cull topic branches
that have been merged to their final destination, and list possible
backporting for older maintenance series.
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Markus Heidelberg @ 2009-03-19 19:32 UTC (permalink / raw)
To: Eric Raible; +Cc: Santi Béjar, Eric Raible, git
In-Reply-To: <279b37b20903181029q7a526168y360874a48783d1dc@mail.gmail.com>
Eric Raible, 18.03.2009:
> On Wed, Mar 18, 2009 at 10:04 AM, Santi Béjar <santi@agolina.net> wrote:
> > Gitk paints lines of development (lineal history without merges nor
> > forks) with the same color.
> >
> > HTH,
> > Santi
>
> Thanks for the quick reply. I suppose I realized that but it just
> doesn't seem that profound.
> Don't get me wrong - I like gitk and still prefer it to any of the alternatives.
> But its of color seems more flashy than useful to me.
If scrolling through a history with many branches (so many parallel
lines) like git.git, colors help you to follow a particular line.
I don't find it easy to follow a line in a PCB, where you normally don't
have colors :)
Markus
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-19 19:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: david, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de>
On Thu, Mar 19, 2009 at 6:13 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 18 Mar 2009, david@lang.hm wrote:
>
>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:
>>
>> > On Fri, 13 Mar 2009, saurabh gupta wrote:
>> >
>> > > On Fri, Mar 13, 2009 at 1:29 AM, <david@lang.hm> wrote:
>> > > > On Fri, 13 Mar 2009, saurabh gupta wrote:
>> > > >
>> > > > it may be just doing an XML merge driver is a summer's worth of
>> > > > work, or it may be that it's not really enough and you should try
>> > > > to do another one or two.
>> > > >
>> > > > it also may be that there is a lot of overlap between different
>> > > > merge drivers, and once you have the XML driver the others become
>> > > > fairly trivial to do. (I'm thinking the config file examples I
>> > > > posted earlier in the thread)
>> > >
>> > > with the options given to the user, one can handle the config files
>> > > also where order doesn't matter and also the whitespaces problem can
>> > > also be handled in the similar way.
>> >
>> > In my humble opinion, we should focus on the data types we want to be
>> > able to support at the end of the summer first.
>> >
>> > For example, if we decide that OOXML is a must (as it is a proper
>> > standard, and many people will benefit from it), we will most likely
>> > end up in having to write a merge _driver_ (to handle those .zip
>> > files), _and_ a merge _helper_, although we can avoid writing our own
>> > GUI, as we can create an OOXML that has its own version of conflict
>> > markers.
>>
>> do you mean OOXML (the microsoft format) or ODF (the open office
>> format)?
>
> Oops.
>
> EOVERLOAD
>
>> > If we decide that SVG is something we want to support by the end of
>> > the summer, then we can probably avoid writing a merge _driver_, as
>> > plain text is handled reasonably well in Git. OTOH it could turn out
>> > that there are _real_ conflicts in overlapping tag ids, and it would
>> > still be easier to write a merge driver, too.
>> >
>> > IOW the details are not as important as
>> >
>> > - knowing what data types we want to support _at the least_, and what
>> > data types we keep for the free skate,
>> >
>> > - a clear picture of the user interface we want to be able to provide,
>> >
>> > - a timeline (weekly milestones should be fine, I guess) what should
>> > be achieved when, and
>> >
>> > - being flexible in how to support that (IOW if a merge driver appears
>> > unnecessary first, but necessary later, we should be able to fit
>> > that into both the design and the timeline).
>>
>> it's up to the student, but I suspect that the best approach would be to
>> start with defining a merge driver to handle XML (with a minimum set of
>> capabilities, and additional optional ones), and go from there.
>
> Well, the thing is: if the student decides to have a go at an XML driver
> first and foremost, then I'll just flatly refuse to mentor that. Because
> I sincerely believe that this project is best designed from top to bottom,
> not the other way round.
>
> After all, the project is based on a user's request, not just a
> playthingie for an XML enthusiast (if such a thing exists).
I do agree with you that unless an end user get to see the conflict
result in an appropriate manner, there is no use of having an xml
merger. But, once we decide as what will be the end file type which we
will aim this summer, we can then start working whether its about
making a GUI first, or creating a merge driver first.
> Ciao,
> Dscho
>
>
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: saurabh gupta @ 2009-03-19 19:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: david, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de>
Hi all,
Sorry for replying so late as I was busy in my college's mid-semester exams :-|
On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 13 Mar 2009, saurabh gupta wrote:
>
>> On Fri, Mar 13, 2009 at 1:29 AM, <david@lang.hm> wrote:
>> > On Fri, 13 Mar 2009, saurabh gupta wrote:
>> >
>> >> Very well described, David. I agree with you and providing these
>> >> merge options to the user, merge drivers can do the work and mark the
>> >> conflicts according to the option. The work to do is to modify the
>> >> merge driver. I think in this way, even people who have only a
>> >> terminal can also gain from it. They can choose the apt option to see
>> >> the conflict markers in their way. So, the aim is to make merge
>> >> driver configurable and create the merged/conflicted file according
>> >> to the options.
>> >
>> > for the GSOC I suspect that the right thing to do is the define one or
>> > more merge drivers to create, and list what applications are going to
>> > be used for testing these merges.
>> >
>> > you and the mentor can decide what is a reasonable amount of work.
>>
>> I will very glad to hear about this thing from the mentor (Johannes
>> Schindelin, according to wiki). I will try to plan out the things in a
>> proper way to carry out this project if I get a chance to work on this
>> for GSoC 2009.
>
> Well, now that we have been accepted as an organization, we can move
> forward with this idea!
Congrats for getting accepted in GSoC 2009.
> My main concern is that we define early on what should be the user
> interface, preferably with a quick sketch.
>
> The technical details, we can hash them out later, I have no doubt that
> with the help of the complete Git community, we can overcome almost every
> problem handling XML data or some such.
>
>> > it may be just doing an XML merge driver is a summer's worth of work,
>> > or it may be that it's not really enough and you should try to do
>> > another one or two.
>> >
>> > it also may be that there is a lot of overlap between different merge
>> > drivers, and once you have the XML driver the others become fairly
>> > trivial to do. (I'm thinking the config file examples I posted earlier
>> > in the thread)
>>
>> with the options given to the user, one can handle the config files
>> also where order doesn't matter and also the whitespaces problem can
>> also be handled in the similar way.
>
> In my humble opinion, we should focus on the data types we want to be
> able to support at the end of the summer first.
>
> For example, if we decide that OOXML is a must (as it is a proper
> standard, and many people will benefit from it), we will most likely end
> up in having to write a merge _driver_ (to handle those .zip files), _and_
> a merge _helper_, although we can avoid writing our own GUI, as we can
> create an OOXML that has its own version of conflict markers.
Well, for ODF type document, we can write a merge driver which will
change the xml file in an appropriate way that OO can understand it
and the user can see the merge result/conflict in a comfortable way.
As described by Junio, in this case, a dedicated merge helper is not
needed as OO can parse the markers made by merge-driver and provide
the user to resolve the conflict and register the changes to index.
>
> If we decide that SVG is something we want to support by the end of the
> summer, then we can probably avoid writing a merge _driver_, as plain text
> is handled reasonably well in Git. OTOH it could turn out that there are
> _real_ conflicts in overlapping tag ids, and it would still be easier to
> write a merge driver, too.
>
> IOW the details are not as important as
>
> - knowing what data types we want to support _at the least_, and what data
> types we keep for the free skate,
As of now, how about going for XML files. For this summer, we can go
for XML files and latex files can be handled later.
>
> - a clear picture of the user interface we want to be able to provide,
In my opinion, we have following things to do:
=> while merging an ODF document, merge-driver will merge the file at
file level. If changes don't overlap, then it returns the result with
a success. For example, if the file is changed only on one side, then
the driver will simply add the new content.
=> If conflicts appear, then the merge driver will put the markers in
an appropriate manner which the end-user application (e.g. open
office) can understand and show the user. For example, the XML file of
that ODF document will be modified and OO can show it to user in its
way. We will have to study about the OO style of version marking.
Another method is to implement the marker style in our own way. For
example, to show any marker, the XML file is modified so that user can
see markers like ">>>> " or "====" in openoffice....In this case, we
will have to just change the xml content in this way.
>
> - a timeline (weekly milestones should be fine, I guess) what should be
> achieved when, and
Timeline can be decided once we reach some conclusion and the work
which needs to be done become clear to us.
> - being flexible in how to support that (IOW if a merge driver appears
> unnecessary first, but necessary later, we should be able to fit that
> into both the design and the timeline).
>
> How does that sound?
>
> Ciao,
> Dscho
>
>
--
Saurabh Gupta
Senior,
NSIT,New Delhi, India
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-19 19:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903191119340.10279@pacific.mpi-cbg.de>
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
> On Thu, 19 Mar 2009, david@lang.hm wrote:
>
>> all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
>> and a single flexible XML merge driver could potentially handle all
>> three (as well as other formats). for that matter, the ODF specs cover
>> multiple types of data, and I suspect that appropriate conflict markers
>> for text could well end up being different than the ones for
>> spreadsheets.
>
> You are misunderstanding me.
>
> The fact that all three are XML based has nothing to do with the _real_
> goal of the project.
>
> IOW a user trying to 3-way-merge ODF files could not care less if the
> underlying technical details involve having an extra merge driver for XML
> files or not.
>
> The user cares about the ease of use, about the user interface. That is
> what I want to focus on.
>
> And if we end up with a beautiful XML merge driver at the end of the
> summer that nobody uses, I will be not only a little disappointed.
>
> So let's look at the _nature_ of the data at hand, i.e. text, marked-up
> text, images (we could include UML, which is also XML-based, and where the
> XML merge driver is as relevant for the user experience as for the
> others), and how to make it _easy_ to resolve merge conflicts there.
but don't you want to be able to auto-merge as much as possible before you
have to go to _any_ user interaction? (the best user interface is one you
don't need to use)
it's only after the merge drive decides that it can't do the merge that
you would have to move on to manually resolving conflicts.
when you _do_ move on to resolving conflicts, it's not a good approach to
write a GUI tool to deal with each datatype (git does not need it's own
ODF text document editory, spreadsheed editor, graphics editor, etc). it
may end up being nessasary for some document types, but that's a last
resort. it's far better if the conflict markers can be inserted in such a
way that the normal tools for dealing with that file type can be used.
git doesn't provide (or mandate) what editor is used to resolve conflicts
in text files today, it should not do so for other file types either
(again, except as a last resort)
the only way to start from the GUI and not create a merge driver first is
to either have a custom GUI that accepts files 'corrupted' with the
existing conflict markers, or work on a GUI that works with both of the
sources as entire files, with no conflict markers or assistance from git.
David Lang
^ permalink raw reply
* Re: [PATCH 2/2] Allow http authentication via prompt for http push.
From: Amos King @ 2009-03-19 19:02 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903191755270.6357@intel-tinevez-2-302>
The issue with calling it remote is that it conflicts with the remote
struct that is need for http_init, and is used in the rest of the
code. So do you want me to make this small impact change or a larger
and more broad sweeping change by changing the name of the other
remote. I don't believe fake is a better name. I would hope that at
some point the 'repo' struct would go away and we can make http_push
work like all the other remote commands.
I also believe that 'out' is the correct word. It was not a typo, and
I appreciate your suggestion of assuming that I can't spell just
because I used a word that you didn't understand. I'm not building
OUR authorization. I am building OUT authorization. Have you heard
of building something out? Or even fleshing something out?
I appreciated your first responses to my other patch. Even if your
tone was that of a person with low self-esteem who needs to pick
unimportant details apart in order to stroke their own ego. Instead
of responding in the same tone I thought I would respond nicely and
get your feedback. Responses like your first one don't cause people
to want to continue to contribute to the community.
I have a great idea. Why don't you try using the 'nice' tense in your
next email instead of the high and mighty 'ass-hole' tense. Then I
will gladly not use past tense in my commit messages, and others might
respond more positively to your criticisms.
Fiek Dich,
Amos
On Thu, Mar 19, 2009 at 11:59 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Thu, 19 Mar 2009, Amos King wrote:
>
>> There is now a faux remote created in order to
>> be passed to http_init.
>>
>> Signed-off-by: Amos King <amos.l.king@gmail.com>
>> ---
>> http-push.c | 11 ++++++++++-
>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>
>> diff --git a/http-push.c b/http-push.c
>> index 9ac2664..468d5af 100644
>> --- a/http-push.c
>> +++ b/http-push.c
>> @@ -2195,7 +2195,16 @@ int main(int argc, char **argv)
>>
>> memset(remote_dir_exists, -1, 256);
>>
>> - http_init(NULL);
>> + /*
>> + * This is a faked remote so that http_init can
>> + * get the correct data for builidng out athorization.
>> + */
>
> You might want to pass this through aspell ;-) Altough it will not
> suggest 'out ->our', I guess...
>
>> + struct remote *remote;
>> + remote = xcalloc(sizeof(*remote), 1);
>> + ALLOC_GROW(remote->url, remote->url_nr + 1, remote->url_alloc);
>> + remote->url[remote->url_nr++] = repo->url;
>> +
>> + http_init(remote);
>
> Would 'fake' not be a more appropriate name than 'remote'?
>
> That would also make the patch 1/2 rather unnecessary (I also have to
> admit that I do not find 'repo' a better name, as we have a repository
> both locally and remotely, and this _is_ the remote repository, not the
> local one).
>
> Ciao,
> Dscho
>
>
--
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
^ permalink raw reply
* [PATCH] Re: git-gui: various French translation fixes
From: Nicolas Sebrecht @ 2009-03-19 18:38 UTC (permalink / raw)
To: Sam Hocevar; +Cc: Christian Couder, Git List, Alexandre Bourget
In-Reply-To: <20090319124901.GM27280@zoy.org>
On Thu, Mar 19, 2009 at 01:49:02PM +0100, Sam Hocevar wrote:
>
> On Thu, Mar 19, 2009, Sam Hocevar wrote:
> > On Thu, Mar 19, 2009, Christian Couder wrote:
> > > > > #: git-gui.sh:2484 lib/index.tcl:410
> > > > > msgid "Revert Changes"
> > > > > -msgstr "Annuler les modifications (revert)"
> > > > > +msgstr "Révoquer les modifications"
> > > >
> > > > I am not sure that "Révoquer" is better than "Annuler".
> > >
> > > Perhaps "Inverser"?
[...]
> Sorry, I misread the Wikipedia interface because I wasn't logged in
> and only admins can truly revert edits.
I don't think that we have to conform to Wikipédia.
> So it does have "revert" (to
> cancel an edit) and "undo" (to perform the opposite edit of a given
> edit), which get translated to "révoquer" and "défaire". I therefore
> think "révoquer" is just as good as the others.
I disagree here.
"Annuler", "Révoquer", "Inverser" or "Défaire" usualy stands for the
same thing but :
- thoses words doesn't have stricly the same meanings ;
- we are in a special case here because of the underlying technical
result.
We should care that the revert operation does *not* remove a commit but
add a new one (this makes sense to Git). As a consequence, we should avoid
"Annuler", "Révoquer" and "Défaire".
"Inverser" looks like the best translation.
--
Nicolas Sebrecht
^ permalink raw reply
* question about conflict resolution across multiple branches
From: William Morgan @ 2009-03-19 17:56 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I have a git usage question about topic branches and conflicts.
I maintain a project that I believe follows the standard topic branch
model. It has two "version" branches, master and next. When a new
feature is introduced, I create a topic branch off of master, commit,
and merge the topic into next. Users can check out next to play with all
the latest goodies. If a topic branch has problems, I add bugfix commits
to it, and re-merge into next. Once it seems stable, I merge it into
master. (Branching topic branches from master is necessary in order to
be able to merge them into master without pulling everything else that's
in next.)
So this is nice, because I can pick and choose which features to have in
master, more or less independently of each other. The one thing I
haven't been able to figure out is this:
Sometimes those topic branches are remote branches on someone else's
repo. What happens when merging a remote topic branch into next creates
a conflict? Ideally I'd like for the topic branch author to deal with
resolving the conflict, and leave me to my carefree maintainer existence
of eating icecream on the couch. In the no-conflict case, I merge their
remote branch directly into my local next. But in the case of conflicts,
it seems like me only way to acquire their resolution is to merge their
next branch entirely into mine. Is that true?
Likewise, what happens when someone sends a patch against master to the
mailing list, and applying that patch to next creates a conflict? Is
there any way for them to resolve the conflict, and pass that resolution
to me?
Thanks for any help.
--
William <wmorgan-git@masanjin.net>
^ permalink raw reply
* Re: Push tag from shallow clone?
From: Shawn O. Pearce @ 2009-03-19 18:02 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0903191056w4efdbec6hd1656d7b47d0d8a3@mail.gmail.com>
skillzero@gmail.com wrote:
> The documentation for git clone says that if you use --depth=1 to make
> a shallow clone that you can't push it. But I made a shallow clone,
> created a tag, then tried to push that tag and it worked. Am I just
> getting lucky or is it safe to push a tag with a shallow clone?
Yea, you are getting lucky. The tag is easily identified as one
object head of the current branch on the remote, and the client is
able to produce the pack and send it.
If the remote branch gets modified in the interm, the builder may
not be able to deduce what it needs to send, and will attempt to
pack a lot more data, potentially finding the missing parents from
where it is shallow.
Why not just have a central area on the build server that keeps
full clones of everything, and use "git clone -s" or "git clone
--reference" in order to create the new work area for the builder?
--
Shawn.
^ permalink raw reply
* Push tag from shallow clone?
From: skillzero @ 2009-03-19 17:56 UTC (permalink / raw)
To: git
The documentation for git clone says that if you use --depth=1 to make
a shallow clone that you can't push it. But I made a shallow clone,
created a tag, then tried to push that tag and it worked. Am I just
getting lucky or is it safe to push a tag with a shallow clone?
The reason I ask is that we have an automatic builder/tester/archiver
where I'd like to make a shallow clone (to save space since it only
needs the tip of the branch to do the build), do the normal build and
test and if it all passes, tag it, and push the tag so people can pull
tags that have been verified by the automated builder.
^ permalink raw reply
* Re: git svn unhandled.log compression
From: Eric Wong @ 2009-03-19 17:55 UTC (permalink / raw)
To: Tim Blechmann; +Cc: Sverre Rabbelier, git
In-Reply-To: <49C23815.5010204@klingt.org>
Tim Blechmann <tim@klingt.org> wrote:
> >> i am not familiar with the git svn codebase, so i am not sure, whether
> >> it is feasible to implement a compression of the unhandled.log files,
> >> but it would definitely save me quite a lot of hd space ...
> >
> > On that note, Eric, what does the unhandled.log file do in the first
> > place? It's name would suggest it lists all revisions that aren't
> > handled yet, but the contents of the file seem to only grow over time,
> > what gives?
>
> according to the man page, it logs unhandled svn properties
Yup, it logs things that git-svn currently cannot handle. It's meant to
be machine parseable so other tools[1] can process them after-the-fact.
I would accept a patch for a command like "git svn gc" to deal with
compressing them.
[1] - as far as I know there are none
--
Eric Wong
^ permalink raw reply
* Re: Msysgit 1.6.2 cannot clone from network drive
From: Johannes Schindelin @ 2009-03-19 17:49 UTC (permalink / raw)
To: Henk; +Cc: git
In-Reply-To: <1237483985187-2504254.post@n2.nabble.com>
Hi,
On Thu, 19 Mar 2009, Henk wrote:
> I recently installed Msysgit 1.6.2 and noticed that using this version I
> cannot clone from (mapped) network drive anymore. This does work in Msysgit
> 1.6.1. I double checked this on the computer of a coworker.
>
> We use Windows Vista Professional and are using active directory. Is this a
> known bug?
Yes. It goes by the number 204.
Oh, and it is fixed, and the fix will be part of the next release.
There are a few things holding up a new release:
- there has been a bug report about "WARNING: terminal is not fully
functional" that I do not understand yet,
- there has been a bug report that adjust_perm() fails while cloning, and
I do not understand that either,
- Hannes was busy with fixing the test suite, and I am not decided yet if
I'd rather wait with Git-1.6.2.1-preview, or not, and
- there have been a lot of duplicate bug reports that are taking my scarce
time away from preparing the release. :-)
Ciao,
Dscho
^ permalink raw reply
* Re: Adding History
From: Shawn O. Pearce @ 2009-03-19 17:47 UTC (permalink / raw)
To: Roger Garvin; +Cc: git
In-Reply-To: <loom.20090319T173541-173@post.gmane.org>
Roger Garvin <yoyodyn@gmail.com> wrote:
> Is there a way to add history to a repository?
> We have just started using git, where before we had nothing but backup
> directories all over the place. We created the git repository using our
> existing source directory. Is there a way to now go and add some of the backup
> source directories to the history? Or would this break all the SHA1 of the
> current objects?
Right, you need to change the SHA-1 of all of the commits in order
to insert history in the past.
> I am not sure it would be worth it at this point. But we are
> still pretty early in our use of git so now would be the easiest time.
You have two options:
- Use git-filter-branch now to rewrite your commits with the
history added. Its a one-time pain that you need to go through to
discard all of your current objects, and move to the new ones that
have the history.
- Keep the current objects, but if you need the history, add it
to the local repository by editing the grafts file. This is how
the Linux kernel team can insert history that predates Git, if
they absolutely must have it.
It depends on how often you need to look at that history. If its
"almost never", I would probably go with the graft. If its "often",
I would consider the filter-branch now.
--
Shawn.
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Johannes Schindelin @ 2009-03-19 17:41 UTC (permalink / raw)
To: Allan Caffee; +Cc: git
In-Reply-To: <b2e43f8f0903190959if539048r19e972899bd2132d@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Allan Caffee wrote:
> Hello and thanks for the speedy reply!
Heh, Git is known for raw speed ;-)
> On Wed, Mar 18, 2009 at 7:44 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > On Wed, 18 Mar 2009, Allan Caffee wrote:
> >
> > > Is anybody else interested in seeing this?
> >
> > Count me in. Are you interested in implementing this?
>
> I'll give it a go. Been a while since I've done anything of substance
> in pure C so it should be a nice refresher. :)
Great!
> > If so:
> >
> > - you need to #include "color.h" in graph.c
> >
> > - you need to insert a color identifier into struct column (there is an
> > XXX comment at the correct location)
>
> By color identifier I assume you mean the ANSI escape sequence, right? I
> didn't see a type for representing colors in color.{c,h} other than the
> int it seems to use internally.
I'd actually add an enum color_names, or something like that.
> > - you need to find a way to determine colors for the branches
>
> Okay, so if we were to make this similiar to how gitk works it would
> involve: If the previous commit was a merge:
> for (i = 0; i < graph->num_columns; i++)
> graph->columns[i]->color = get_next_column_color();
> else
> get_current_column_color();
>
> I was thinking of storing the current color by adding a
> default_column_color attribute to git_graph that serves as an index into
> column_colors. column_colors being the array of available colors.
Yep, I agree. That index could be of type "enum color_names" if you
introduce the latter...
> > - you need to put the handling into the function
> > graph_output_pre_commit_line() in graph.c (and probably
> > graph_output_commit_char(), graph_output_post_merge_line(),
> > graph_output_collapsing_line(), graph_padding_line(), and
> > graph_output_padding_line(), too)
> >
> > - it would make sense IMHO to introduce a new function that takes a
> > pointer to an strbuf, a pointer to a struct column and a char (or
> > maybe a string) that adds the appropriately colorized char (or
> > string) to the strbuf
>
> That makes sense. Then we can just update the functions you mentioned
> above to use this.
Right.
> > - use the global variable diff_use_color to determine if the output
> > should be colorized at all
>
> The function for adding a column to an strbuf would offer a convenient
> place to put the condition.
Yes!
> > - probably you need to make an array of available colors or some such
> > (which might be good to put into color.[ch])
>
> This would be the color_codes array I mentioned but it seems like it
> might belong in graph.c. There's something similiar in diff.c and it
> seems like this is more related to graphing then to colors in general.
> Although I do think it makes sense to #define some of the more common
> ANSI codes there so that they don't have to be duplicated. grep shows 6
> occurrences of '\033[31m', the code for red foreground.
I'd actually like to see it in color.[ch], so that other code paths can
use it, too.
I'd start like this:
enum color_name {
COLOR_RESET,
COLOR_RED,
COLOR_GREEN,
COLOR_YELLOW,
COLOR_BLUE,
COLOR_MAGENTA,
COLOR_CYAN,
COLOR_WHITE
};
Maybe the best thing would then be to add a function
void strbuf_add_color(struct strbuf *buf, enum color_name name) {
if (name == COLOR_RESET)
strbuf_addf(buf, "\033[m");
else
strbuf_addf(buf, "\033[%dm", 31 + name - COLOR_RED);
}
Ciao,
Dscho
^ permalink raw reply
* Adding History
From: Roger Garvin @ 2009-03-19 17:38 UTC (permalink / raw)
To: git
Is there a way to add history to a repository?
We have just started using git, where before we had nothing but backup
directories all over the place. We created the git repository using our
existing source directory. Is there a way to now go and add some of the backup
source directories to the history? Or would this break all the SHA1 of the
current objects? I am not sure it would be worth it at this point. But we are
still pretty early in our use of git so now would be the easiest time.
Roger
^ permalink raw reply
* keeping track of what a branch is for
From: E R @ 2009-03-19 17:36 UTC (permalink / raw)
To: git
Ok - here's another one...
I've started to create a lot of branches (like one per feature I'm
working on), but I'm starting to have trouble keeping track of what
each branch is for. Also, I'd like to keep track of a todo list for
each branch.
Is there a good way to keep track of these details with git? Using a
repository file kinda works except when merging back into the master
branch.
^ permalink raw reply
* Msysgit 1.6.2 cannot clone from network drive
From: Henk @ 2009-03-19 17:33 UTC (permalink / raw)
To: git
I recently installed Msysgit 1.6.2 and noticed that using this version I
cannot clone from (mapped) network drive anymore. This does work in Msysgit
1.6.1. I double checked this on the computer of a coworker.
We use Windows Vista Professional and are using active directory. Is this a
known bug? Currently I am forced to switch back to version 1.6.1 and I
consider falling back to this version in GitExtensions.
--
View this message in context: http://n2.nabble.com/Msysgit-1.6.2-cannot-clone-from-network-drive-tp2504254p2504254.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: fatal: bad object HEAD
From: Rostislav Svoboda @ 2009-03-19 17:24 UTC (permalink / raw)
To: git
In-Reply-To: <286817520903190955n2e27abb6ydd52d9ddcffccbc7@mail.gmail.com>
I tried
$ git fsck --verbose
Checking tree fe217057862c74e6c1a0cf12e39b941f967927b2
Checking blob fe56c41c028f320bb474ca9e0fe15baa2b0aa122
Checking blob fe7c85910717d546ee002bb64a9d1476a9451eed
error: refs/heads/branch_1 does not point to a valid object!
error: refs/heads/branch_2 does not point to a valid object!
error: refs/heads/branch_3 does not point to a valid object!
error: refs/heads/branch_4 does not point to a valid object!
error: refs/heads/master does not point to a valid object!
Checking reflog
3d7d1cf8f8edae21d90be9d84c21b5ac65ee94dc->9e53015709777b533717b25687295407f38f840e
Checking reflog
9e53015709777b533717b25687295407f38f840e->695e934882e78fb85b78649dea5109aa69855a88
...
and deeper in the output there are 4 suspicious entries:
Checking reflog
0000000000000000000000000000000000000000->696bd2fc4a8554891976af42e65ccaf9d12009ac
Checking reflog
0000000000000000000000000000000000000000->aff44ac2a61607dd95caadd896e2cae51e4dfdcf
Checking reflog
0000000000000000000000000000000000000000->6f20af9bcc1f446116cc1af238cb849ca1ccd385
Checking reflog
0000000000000000000000000000000000000000->696bd2fc4a8554891976af42e65ccaf9d12009ac
I think here might the problem. Can anyone explain me what it means? thx a lot
Bost
On Thu, Mar 19, 2009 at 17:55, Rostislav Svoboda
<rostislav.svoboda@gmail.com> wrote:
> Hi people, I have a BIG trouble:
>
> $ git fsck
> error: refs/heads/branch_1 does not point to a valid object!
> error: refs/heads/branch_2 does not point to a valid object!
> error: refs/heads/branch_3 does not point to a valid object!
> error: refs/heads/master does not point to a valid object!
> (and quite many missing and dangling blobs)
>
> I use msysGit 1.6.1-preview20081227 and I did:
> $ git checkout master
> $ git gui
>
> here I got again and again that stupid error message
> 'file fname.ext has been modified but no changes detected' so I did
> $ git add fname.ext
> $ git branch branch_1 (here I did a mistake. I wanted to do 'git
> checkout branch_1' )
>
> And now is _everything_ seems to be lost... uaaaa :( What can I do now?
> Any would be REALLY appreciated
>
> Bost
>
^ permalink raw reply
* Re: [PATCH 2/2] Allow http authentication via prompt for http push.
From: Johannes Schindelin @ 2009-03-19 16:59 UTC (permalink / raw)
To: Amos King; +Cc: git, Junio C Hamano
In-Reply-To: <d8c371a80903190812w59febbd3qc6bc3d70ce85f76e@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Amos King wrote:
> There is now a faux remote created in order to
> be passed to http_init.
>
> Signed-off-by: Amos King <amos.l.king@gmail.com>
> ---
> http-push.c | 11 ++++++++++-
> 1 files changed, 10 insertions(+), 1 deletions(-)
>
> diff --git a/http-push.c b/http-push.c
> index 9ac2664..468d5af 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -2195,7 +2195,16 @@ int main(int argc, char **argv)
>
> memset(remote_dir_exists, -1, 256);
>
> - http_init(NULL);
> + /*
> + * This is a faked remote so that http_init can
> + * get the correct data for builidng out athorization.
> + */
You might want to pass this through aspell ;-) Altough it will not
suggest 'out ->our', I guess...
> + struct remote *remote;
> + remote = xcalloc(sizeof(*remote), 1);
> + ALLOC_GROW(remote->url, remote->url_nr + 1, remote->url_alloc);
> + remote->url[remote->url_nr++] = repo->url;
> +
> + http_init(remote);
Would 'fake' not be a more appropriate name than 'remote'?
That would also make the patch 1/2 rather unnecessary (I also have to
admit that I do not find 'repo' a better name, as we have a repository
both locally and remotely, and this _is_ the remote repository, not the
local one).
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Colorization of log --graph
From: Allan Caffee @ 2009-03-19 16:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0903181228420.10279@pacific.mpi-cbg.de>
Hello and thanks for the speedy reply!
On Wed, Mar 18, 2009 at 7:44 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Wed, 18 Mar 2009, Allan Caffee wrote:
>
> > I know that _some_ people arn't particularly fond of colors, but I was
> > wondering how difficult it would be to colorize the edges on the --graph
> > drawn by the log command? It can be a little tricky trying to follow
> > them with a relatively complex history. I was thinking something like
> > gitk already does.
>
> That's a good idea! (And it is mentioned as a TODO in graph.c...)
That's me, always thinking outside the box. ;-)
> > Is anybody else interested in seeing this?
>
> Count me in. Are you interested in implementing this?
I'll give it a go. Been a while since I've done anything of substance
in pure C so it should be a nice refresher. :)
> If so:
>
> - you need to #include "color.h" in graph.c
>
> - you need to insert a color identifier into struct column (there is an
> XXX comment at the correct location)
By color identifier I assume you mean the ANSI escape sequence, right?
I didn't see a type for representing colors in color.{c,h} other than
the int it seems to use internally.
> - you need to find a way to determine colors for the branches
Okay, so if we were to make this similiar to how gitk works it would involve:
If the previous commit was a merge:
for (i = 0; i < graph->num_columns; i++)
graph->columns[i]->color = get_next_column_color();
else
get_current_column_color();
I was thinking of storing the current color by adding a
default_column_color attribute to git_graph that serves as an index into
column_colors. column_colors being the array of available colors.
> - you need to put the handling into the function
> graph_output_pre_commit_line() in graph.c (and probably
> graph_output_commit_char(), graph_output_post_merge_line(),
> graph_output_collapsing_line(), graph_padding_line(), and
> graph_output_padding_line(), too)
>
> - it would make sense IMHO to introduce a new function that takes a
> pointer to an strbuf, a pointer to a struct column and a char (or maybe
> a string) that adds the appropriately colorized char (or string) to the
> strbuf
That makes sense. Then we can just update the functions you mentioned
above to use this.
> - use the global variable diff_use_color to determine if the output should
> be colorized at all
The function for adding a column to an strbuf would offer a convenient
place to put the condition.
> - probably you need to make an array of available colors or some such
> (which might be good to put into color.[ch])
This would be the color_codes array I mentioned but it seems like it
might belong in graph.c. There's something similiar in diff.c and it
seems like this is more related to graphing then to colors in general.
Although I do think it makes sense to #define some of the more common
ANSI codes there so that they don't have to be duplicated. grep shows 6
occurrences of '\033[31m', the code for red foreground.
I'll begin working on a patch. Comments/questions?
~Allan
^ 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